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1. 


INTRODUCTION 


This  report  explains  how  to  use  the  Reengineering  Tool  (RET)  prototype  developed 
under  the  Avionics  Software  Reengineering  Technology  (ASRET)  project.  The  RET  proto¬ 
type  is  a  software  reengineering  tool  that  assists  in  improving  and  translating  avionics 
simulation  software  written  in  FORTRAN  to  Ada. 


1.1  BACKGROUND 

1.1.1  Context 

We  conducted  the  ASRET  project  under  the  Avionics  Software  Technology  Support 
(ASTS)  program.  The  ASTS  program  is  an  ongoing  activity  of  the  Software  Concepts 
Group,  Avionics  Logistics  Branch  at  Wright  Laboratory  (WL/AAAF-3),  Wright  Patterson 
Air  Force  Base  in  Ohio.  The  objective  of  the  ASTS  program  is  to  perform  research  and  de¬ 
velopment  for  enhancing  Embedded  Computer  System  (ECS)  software  development  and 
postdeployment  support. 

The  main  objective  of  ASRET  was  to  develop  an  automated  Reengineering  Tool 
(RET)  prototype  for  avionics  support  software.  The  specific  goals  included  investigating 
existing  reengineering  and  reverse  engineering  processes,  techniques,  and  software  tools, 
defining  a  reengineering  process  model,  and  building  the  RET  prototype  software  tool. 

1.1.2  Rationale 

The  reengineering  of  software  firom  one  language  to  another  is  becoming  a  neces¬ 
sity  as  Air  Force  organizations  strive  to  modernize  and  improve  the  maintainability  of 
their  systems  while  avoiding  the  excessive  costs  of  new  development.  Systems  that  have 
been  in  use  for  years  often  incur  large  maintenance  costs  for  a  number  of  reasons. 

•  Continual  maintenance  has  made  the  cmrent  implementation  and  original  de¬ 
sign  inconsistent,  the  code  harder  to  understand  and  error-prone,  and  the  doc¬ 
umentation  out-of-date. 

•  They  are  written  in  languages  that  have  fallen  out  of  favor.  The  limited  selec¬ 
tion  of  support  tools  for  these  languages,  the  corresponding  expense  of  the 
associated  support  tools,  and  the  shrinking  pool  of  qualified  programmers  to 
maintain  the  software  adds  to  the  expense  of  maintenance. 
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•  They  were  developed  without  modem  software  engineering  practices,  result¬ 
ing  in  code  that  lacks  structure  and  is  difficult  to  understand. 

•  Employee  turnover  has  reduced  the  staffs  understanding  and  intimate  knowl¬ 
edge  of  the  systems. 

Wright  Laboratory  initiated  the  ASRET  project  to  help  reduce  maintenance  costs  for 
legacy  systems  and  to  assist  in  the  evolution  to  Ada.  To  this  end,  we  developed  an  environ¬ 
ment  for  reengineering  software  from  one  language  to  another.  We  concentrated  on  the 
reengineering  of  avionics  simulation  software  written  in  FORTRAN  to  Ada,  and  designed 
the  RET  prototype  so  that  additional  languages  could  be  supported  in  the  future. 

1.1.3  Groals 

The  objective  of  the  ASRET  project  was  to  develop  an  automated  RET  protot3rpe  for 
avionics  support  software.  The  specific  goals  included  investigating  existing 
reengineering  and  reverse  engineering  processes,  techniques,  and  software  tools,  defin¬ 
ing  a  reengineering  process  model,  and  building  a  RET  prototype  that  supports: 

•  Translating  avionics  simulation  software  written  in  FORTRAN  to  Ada 

•  Improving  the  software  through  restructuring  techniques 

•  Changing  the  design  of  the  software  so  that  it  is  consistent  with  modem  soft¬ 
ware  engineering  principles 

•  Adding  documentation  that  is  consistent  with  the  software. 


1.2  REPORT  ORGANIZATION 

Section  1  introduces  the  ASRET  project  and  highlights  the  rationale  for,  and  goals 
of  the  Reengineering  Tool  (RET).  Section  2  provides  an  overview  of  the  RET  approach  to 
reengineering  and  describes  the  views  available  through  the  RET  user  interface.  Sec¬ 
tion  3  presents  the  ASRET  Reengineering  Process  Model.  Section  4  illustrates  how  to  ap¬ 
ply  the  process  model  and  demonstrates,  in  the  context  of  reengineering  a  sample 
application,  techniques  that  the  RET  supports.  Section  5  is  a  reference  for  the  RET  User 
Interface.  Appendix  A  defines  acronyms  used  in  this  document. 

The  Avionics  Software  Reengineering  Technology  (ASRET)  Project  Final  Report, 
Volume  I,  Project  Summary,  Account,  and  Results  (Ref.  1)  relates  the  lessons  that  we 
learned  while  developing  the  RET  prototype,  and  provides  information  that  may  help  you 
fully  exploit  the  capabilities  of  the  RET. 
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The  Avionics  Software  Reengineering  Technology  (ASRET)  Project  Final  Report, 
Volume  II,  Reengineering  Tool  (RET)  Diagrams  (Ref.  2),  recounts  our  experiences  in  exer¬ 
cising  the  RET  protot3T3e  and  provides  annotated  output  of  the  RET.  This  information 
may  help  you  interpret  diagrams  that  you  create  with  the  RET  prototype. 
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2. 


RET  OVERVIEW 


2.1  THE  GENERAL  APPROACH 

The  RET  comprises  two  distinct  logical  parts  called  the  Left-Hand  Side  (LHS)  and 
the  Right-Hand  Side  (RHS),  The  LHS  provides  views  of  the  original  FORTRAN  program, 
or  subject  system.  The  RHS  provides  views  of  the  Ada  program  being  developed  (i.e.,  the 
target  system).  The  LHS  allows  you  to  navigate  and  view  aspects  of  the  subject  system, 
but  does  not  support  changing  the  subject  system. 

The  RHS  supports  constructing,  refining,  viewing,  and  navigating  the  target  sys¬ 
tem.  You  may  construct  a  basic  structure  for  the  RHS  (macro  restructuring)  using  in¬ 
formation  extracted  firom  the  LHS.  Once  the  basic  structure  of  the  RHS  is  established,  you 
may  refine  the  target  system  (micro  restructuring)  on  the  RHS. 

Semiautomated  RET  components  support  construction  activities;  they  suggest 
large-scale  reorganizations  of  the  subject  system  and  populate  the  RHS  with  the  basic 
structure  of  the  target  system.  The  components  that  support  refinement  allow  you  to  in¬ 
tervene  to  apply  your  knowledge  of  the  subject  system  and  application  domain  and  in¬ 
sight,  which  is  beyond  the  semiautomated  support  provided  by  the  RET,  to  modify  and 
improve  the  RHS  representations. 

The  RET  prototype  supports  engineering  an  Ada  program  by  reusing  and  trans¬ 
forming  parts  of  the  FORTRAN  program.  The  process  is  iterative  as  illustrated  in 
Figure  1. 

•  You  may  explore  views  of  the  original  FORTRAN  progreun  that  the  RET  gener¬ 
ates  on  the  LHS. 

•  You  may  select  LHS  entities  such  as  subroutines,  statements,  or  data  elements 
of  the  original  FORTRAN  program. 

•  The  RET  transforms  the  LHS  entities  and  incorporates  them  into  the  RHS. 

•  You  may  explore  views  representing  the  Ada  program  on  the  RHS. 

•  You  may  interactively  or  automatically  refine  the  RHS  through  the  views. 

You  may  repeat  the  cycle,  exploring  the  LHS  to  select  additional  FORTRAN  enti¬ 
ties  to  reuse  in  building  the  RHS.  The  graphical  user  interface  presents  the  LHS  and  RHS 
views  while  the  object-based  database  manages  the  underlying  data  structures  or  inter¬ 
nal  representations. 
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Figure  1  Developing  Ada  by  Reusing  FORTRAN 


The  RET  approach  to  reengineering  is  to  create  a  new  program  on  the  RHS,  reusing 
components  of  the  LHS.  Structured  design  and  programming  principles  are  compatible 
with  the  RET  prototype  and  the  ASRET  Process  Model  described  in  Section  3. 

The  specific  steps  that  you  may  take  to  apply  the  ASRET  Process  Model  when  using 
the  RET  prototype  are  illustrated  in  Figure  2. 

1.  The  RET  prototype  constructs  the  package  and  subprogram  structure  for  the 
RHS.  It  captures  the  subprogram  structure  from  the  LHS,  transfers  it  to  the 
RHS,  and  clusters  the  subprograms  into  Ada  packages. 

2.  You  may  refine  the  RHS  structure  so  that  related  subprograms  and  data  items 
are  grouped  together  into  packages. 

3 .  The  RET  prototype  moves  data  items  and  type  declarations  from  the  LHS  to  the 
packages  and  subprograms  on  the  RHS  to  which  they  are  most  closely  related. 
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2.2 


Construct 

Program 

Structure 


Redistribute 
the  Declarations 


Rearrange 
ie  Structure 


Add  Data  item 
Declarations 


Add  Program 
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Figure  2  Incorporating  Macro  and  Micro  Entities 


4.  You  may  then  refine  and  redistribute  the  declarations.  For  example,  data  items 
that  are  closely  related  but  used  by  several  subprograms  might  be  in  different 
packages,  and  thus  need  to  be  grouped  together.  As  another  example,  data  items 
might  be  moved  into  or  out  of  a  package’s  private  part  to  reflect  their  scope. 

5.  At  this  point,  the  RHS  contains  the  modular  structure  of  the  program.  The 
RET  prototype  then  transforms  statements  fi’om  the  LHS  and  moves  them  to 
the  bodies  of  the  RHS  subprograms  and  packages. 

6.  Y)u  may  then  refine  individual  statements  on  the  RHS  to  tune  the  RHS  structure. 


THE  USER  INTERFACE 

The  RET  provides  the  views  listed  in  Table  1. 


Table  1  ReengineeringTool  (RET)  Views 


LHS 

RHS 

VIEW 

NAME 

DISPLAYS 

SCL 

Source  Code  Listing 

FORTRAN  or  Ada  source  code 

PACK 

Packager  Diagram 

Ada  package  structure 

DED 

Declaration  Diagram 

FORTRAN  declaration  nesting  structure 

CD 

Call  Diagram 

FORTRAN  subprogram  calling  structure 

DFD 

Data  Flow  Diagram 

Data  flow  through  the  Ada  program 
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•  The  Source  Code  Listing  (SCL)  shows  the  FORTRAN  source  code  after  proc¬ 
essing  by  the  SPAG  component  of  plusFORT  (Ref.  3)  on  the  LHS  and  the  gener¬ 
ated  Ada  code  on  the  RHS. 

•  The  Packager  view  (PACK)  is  a  graphical  view  that  shows  the  package  and 
subprogram  nesting  structure,  and  provides  an  interface  for  developing  the 
Ada  package  structure  on  the  RHS. 

•  The  Declaration  Diagram  (DED)  is  a  textual  view  that  documents  the 
FORTRAN  system  declaration  structure.  The  DED  provides  information  on 
common  blocks,  subprograms,  and  data  objects. 

•  The  Call  Diagram  (CD)  is  a  textual  view  that  documents  the  FORTRAN  calling 
structure.  The  CD  shows  which  subprograms  call,  or  are  called  by  other 
subprograms. 

•  The  Dataflow  Diagram  (DFD)  is  a  graphical  view  that  documents  the  Ada  sys¬ 
tem  data  flow.  The  DFD  is  a  hierarchy  of  dataflow  graphs  that  show,  in  increas¬ 
ing  detail,  how  data  repositories  are  transformed  by  the  Ada  subprograms. 

2.2.1  SCL 

The  Source  Code  Listing  (SCL)  is  a  textual  view  that  shows  the  FORTRAN  or  gen¬ 
erated  Ada  source  code.  The  LHS  SCL  displays  the  FORTRAN  code  as  it  was  formatted 
during  input  to  the  RET  prototype,  after  it  was  processed  by  SPAG.  SPAG  alters  the 
source  code,  so  the  output  format  is  generally  different  from  that  of  the  original  unpro¬ 
cessed  FORTRAN  code.  The  SCL  shows  individual  FORTRAN  subprograms. 

2.2.2  PACK 

The  Packager  view  (PACK)  is  a  hierarchy  of  graphs.  The  hierarchy  corresponds  to  the 
nesting  structure  of  the  target  system.  There  is  one  graph  for  the  Ada  Mbrary,  and  one  for 
each  potential  package.  The  nodes  in  each  graph  represent  modules,  i.e.,  subprograms  or 
packages,  and  the  edges  represent  either  data  binding  relationships  or  subprogram  calls. 
Section  4.1.1  describes  the  Packager  view  and  how  it  is  used  to  cluster  a  sample  apphcation. 

The  Packager  view  contains  two  kinds  of  edges.  Thin,  imdirected  edges  depict  the 
data  sharing  relationships  between  two  nodes.  A  thin  edge  between  two  subprograms  in¬ 
dicates  that  the  two  subprograms  share  data.  A  thin  edge  between  a  package,  P,  and  a 
package  or  subprogram  node  indicates  that  at  least  one  subprogram  in  P  shares  data  with 
the  modtdes  that  the  other  node  represents.  The  edge  labels  list  the  data  objects  or  show 
the  subprograms  in  the  package  that  share  data. 
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A  thick  edge  drawn  as  an  arrow  directed  from  one  subprogram  to  another  represents 
a  subprogram  call  in  the  direction  of  the  arrow.  If  the  edge  is  drawn  between  a  package  and 
another  node,  then  the  edge  may  represent  multiple  subprogram  calls  and  its  label  shows 
either  the  number  of  subprogram  calls  or  the  names  of  the  called  subprograms. 

2.2.3  DED 

The  Declaration  Diagram  (DED)  is  a  textual  view  that  shows  the  declaration  struc¬ 
ture  of  the  subject  system.  The  DED  hsts  the  subprograms,  common  blocks,  and  data  objects 
for  the  FORTRAN  system.  For  each  subprogram,  it  lists  the  formal  parameters,  local 
constants  and  variables,  and  included  files.  For  each  variable,  constant,  and  parameter,  the 
DED  shows  the  data  type  and  describes  where  the  data  object  is  declared  and  referenced. 

2.2.4  CD 

The  Call  Diagram  (CD)  is  a  textual  view  that  shows  the  calling  structure  of  the 
FORTRAN  system.  The  CD  Hsts  the  subprograms  that  comprise  the  original  system  and 
shows  the  subprograms  that  each  one  calls,  and  the  subprograms  that  are  called  by  each 
one.  The  CD  initially  shows  a  list  of  subprograms  and  allows  you  to  view  the  additional 
calling  information  for  the  subprograms  of  your  choice. 

2.2.5  DFD 

The  Dataflow  Diagram  (DFD)  view  is  a  hierarchy  of  dataflow  graphs.  The  hierar¬ 
chy  corresponds  to  the  calling  structure  of  the  target  system.  There  is  one  graph  for  each 
subprogram  declared  in  the  target  system  that  is  called.  This  means  that  there  are  no 
graphs  associated  with  undefined  external  subprograms  or  intrinsic  functions  (because 
you  may  not  have  their  source  code). 

The  DFD  contains  transform  and  repository  nodes.  Three  kinds  of  transform 
nodes  model  programs: 

1.  Nonterminal  (or  call)  nodes  represent  subprograms  that  are  associated 
with  graphs  because  they  call  other  subprograms. 

2.  Terminal  (or  leaf)  nodes  model  subprograms  that  don’t  call  any  other  sub¬ 
programs  and  thus  have  no  graphs. 

3.  Body  nodes  represent  subprogram  bodies. 

Two  flavors  of  repository  nodes  model  data. 

1.  Buffer  nodes  represent  data  objects  (local  variables,  global  variables  such  as 
those  declared  in  Ada  packages,  and  subprogram  parameters). 

2.  Repository  collection  (or  record)  nodes  combine  sets  of  repository  nodes. 
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Arrows  between  the  transform  and  repository  nodes  indicate  the  flow  of  data. 
Transform  nodes  are  labeled  with  subprogram  names.  Repository  nodes  are  labeled  with 
data  item  names.  Repository  collection  nodes  representing  more  than  a  few  (you  may 
specify  the  threshold)  data  items  display  the  total  number  of  data  items,  and  you  may 
click  on  the  collection  nodes  to  view  the  individual  data  item  names.  The  collections  may 
be  nested. 

The  DFD  doesn’t  show  nodes  for  intrinsic  functions  or  external  subprograms.  In¬ 
trinsic  functions  are  those  listed  in  Appendix  D.3  of  the  VAX  FORTRAN  Language  Refer¬ 
ence  Manual  (LRM)  (Ref.  4).  Examples  are  SIN  and  SQRT.  External  subprograms  are 
system  routines,  listed  in  Appendix  D.4  of  the  LRM,  that  are  called  from  the  FORTRAN 
system.  Examples  are  DATE  and  EXIT. 

The  DFD  automatically  eliminates  redimdant  transform  nodes.  For  exaunple,  if 
modiile  A  called  module  B  three  times  and  different  actual  parameters  are  supplied  for 
each  call,  then  the  diagram  for  module  A  would  contain  three  distinct  nodes,  each  labeled 
“B,”  representing  the  three  calls  to  module  B.  The  three  nodes  would  only  be  connected  to 
different  repository  nodes  in  the  diagram  if  different  actual  parameters  were  used  in  each 
of  the  calls.  The  RET  prototype  only  generates  one  “B”  node  if  the  same  actual  parameters 
are  used  in  each  call. 

The  DFD  may  combine  sets  of  repository  nodes  into  collections.  This  is  analogous 
to  combining  several  variables  into  a  record  structure.  The  strategy  reduces  the  number 
of  repository  nodes  in  a  graph.  It  is  most  effective  if  each  of  the  repository  nodes  in  a  collec¬ 
tion  are  referenced  more  or  less  by  the  same  set  of  modules.  The  capability  is  experimental 
so  the  RET  prototype  doesn’t  provide  a  user  interface  for  specifying  the  groupings.  You 
may  specify  the  grouping  by  following  the  example  in  the  RET  protot3T)e  soimce  code  file 
“dfd-record-map.re”  to  produce  collections. 
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REENGBNJEERBVG  PROCESS  MODEL 


The  software  reengineering  process  model  for  the  RET  protot3rpe  is  illustrated  in 
Figure  3.  Steps  in  the  process  label  the  boxes  in  the  figure,  and  inputs  and  outputs  for 
each  step  label  the  icons  between  boxes. 
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The  process  model  specifies  a  set  of  tasks  (the  steps  of  the  process)  that  should  be 
performed  and  the  sequence  in  which  they  should  be  performed  to  reengineer  a  program 
written  in  FORTRAN  to  Ada.  The  process  model  also  specifies  the  information  necessary 
and  desirable  to  support  these  tasks.  The  process  model  does  not  specify  how  the  tasks  are 
to  be  performed  (i.e.,  they  might  be  automated,  as  many  are  in  the  RET,  or  they  might  be 
performed  manually). 

The  first  step  in  the  process  model  is  to  perform  some  preliminary  restructuring  of 
the  source  code  of  the  original  implementation.  Preliminary  restructining  improves  the 
layout  of  the  source  code  by  removing  unstructured  program  constructs,  such  as  CxOTO 
statements,  dead  code,  and  implicit  types.  Preliminary  restructuring  is  separated  fi-om 
the  later  restructuring  step  because  it  can  be  completely  automated  by  commercial  tools, 
and  placed  first  in  the  process  model  because  the  structured  version  of  the  source  program 
is  usually  easier  to  analyze,  understand,  and  restructure. 

After  preliminary  restructuring  is  complete,  the  RET  analyzes  the  improved  source 
code  and  constructs  representations  of  the  program.  Some  of  the  representations,  such  as 
abstract  syntax  graphs  (ASGs)  and  symbol  tables,  are  machine-readable  representations 
used  only  by  automated  restructuring  and  redesign  tasks.  Others,  such  as  flow  graphs 
and  structure  charts,  aid  in  program  understanding,  redocumentation,  and  manual  re¬ 
structuring.  For  manual  restructuring,  the  set  of  representations  contains  a  source  code 
listing. 

You  may  perform  the  restructuring,  redesign,  and  redociunentation  steps  multiple 
times,  each  time  building  upon  the  results  of  the  previous  pass.  A  multipass  approach  is 
necessary  because  it  is  easier  and  less  error-prone  to  reengineer  a  large  program  in  stages, 
verifying  the  program  after  each  pass.  Restructuring  (i.e.,  changing  the  structure  of  the 
program  without  changing  its  fimctionafity)  is  performed  first,  possibly  in  several  passes. 
These  passes  perform  the  following  steps: 

1.  Macro  control  restructuring  groups  statements  and  control  structxires  of  the 
program  into  modules,  such  as  procedures,  functions,  and  packages.  This  in¬ 
cludes  recovering  modules  of  the  original  program,  generating  new  modules, 
and  specifying  a  declaration  nesting  structure  for  modules. 

2.  Macro  data  restructuring  groups  data  items,  such  as  types,  variables,  and 
constants,  and  associates  them  with  modules  created  during  macro  control  re¬ 
structuring.  This  includes  recovering  data  groupings  of  the  original  program, 
creating  new  groupings,  and  creating  abstract  data  types  and  records. 
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3 .  Micro  control  restructuring  manipiilates  individual  control  structures .  This  in¬ 
cludes  the  translation  of  individual  statements  and  functionality-maintaining 
alterations,  such  as  code  lifting  (Ref.  5), 

4.  Micro  data  restructuring  manipulates  individual  data  items.  This  includes  ac¬ 
tions  such  as  translating,  changing  names,  changing  types,  creating  symbolic 
constants,  and  changing  the  scope  of  variables. 


Macro  control  and  data  restructuring  should  be  performed  first  to  develop  a  modu¬ 
lar  structure  for  the  target  system,  followed  by  micro  control  and  data  restructming  to 
restructure  individual  components  of  the  program. 

After  restructuring  is  complete,  the  RET  prototype  generates  code  in  the  target  lan¬ 
guage  and  the  program  is  tested  to  ensure  that  the  restructuring  did  not  introduce  any 
errors  or  undesired  functional  changes.  The  test  data  of  the  original  program  can  be  used 
and  the  results  compared  with  the  results  of  testing  the  original  program.  In  many  cases, 
the  test  data  will  need  to  be  reengineered  to  work  with  the  reengineered  program. 

Any  differences  in  the  results  of  testing  indicate  the  introduction  of  an  unexpected 
functional  change  during  restructuring.  Coverage  analysis  must  be  performed  during  the 
testing  of  the  target  code  because  restructuring  can  introduce  or  alter  control  and  data 
characteristics  of  the  program.  When  an  error  in  the  target  program  is  indicated,  the  pro¬ 
gram  can  be  corrected  by  amending  the  target  code  directly  or  by  restructuring  the  repre¬ 
sentations  and  regenerating  the  target  code. 

Once  you  have  restructured  the  program  and  created  a  fimctionally  equivalent  pro¬ 
gram  in  the  target  language,  you  may  perform  additional  restructuring  and  redesign  ac¬ 
tions  on  the  program.  These  steps  use  the  same  set  of  actions  (i.e.,  macro  control,  macro 
data,  micro  control,  and  micro  data),  but  have  different  goals. 

Further  restructuring  improves  the  structure  of  the  program  without  changing  its 
functionality.  The  goal  of  redesign  is  to  change  the  functionahty  of  the  program  (e.g.,  to 
correct  design  flaws  or  improve  the  design).  If  you  edited  the  target  program  code  to  cor¬ 
rect  errors  indicated  during  testing,  the  RET  analyzes  the  code  to  generate  representa¬ 
tions  before  performing  subsequent  restructxuing  and  redesign.  The  RET  performs 
redocumentation  simultaneously  with  the  restructuring  and  redesign  steps  and  can  save 
the  generated  representations  for  docmnenting  the  program  structtire  and  design. 
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The  RET  reengineering  process  model  includes  modem  software  development  pro¬ 
cesses,  such  as  continuous  testing,  iterative  restructuring  and  redesign,  and  configura¬ 
tion  management.  The  process  model  is  a  specialization  of  the  Chikofsky-Cross  process 
model  (Refs.  6,  7).  The  entire  Chikofsky-Cross  model  is  represented,  although  there  are 
differences: 

•  Program  management  extensions  to  the  process  model  (Ref.  8)  are  included, 
such  as  configuration  management  and  testing. 

•  Easily  automated  steps,  such  as  preliminary  restructuring,  are  separated  so 
they  can  be  addressed  by  commercial  tools. 

•  Chikofsky-Cross  steps  are  decomposed,  such  as  restructuring  into  macro  con¬ 
trol,  macro  data,  micro  control,  and  micro  data  restructuring. 

•  Iteration  steps  that  are  implicit  in  the  Chikofsky-Cross  process  are  explicitly 
introduced. 
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4. 


APPLICATION  OF  CONCEPTS 


The  RET  helps  you  develop  an  Ada  system  by  reusing  parts  of  the  existing  system.  It 
supports,  but  does  not  enforce,  the  ASRET  process  model  by  implementing  macro  and  micro 
restructuring  as  defined  in  Section  3.  You  may  first  apply  macro  restructuring  features  to 
construct  a  skeleton  of  the  Ada  system.  The  skeleton  provides  the  modular  structure  and  the 
distribution  of  variables  among  the  modules.  You  may  then  explore  and  refine  the  Ada  struc¬ 
ture,  and  add  program  statements  using  micro  restructuring  features  of  the  RET. 

This  section  describes  some  problems  that  you  may  face  when  reengineering  a 
legacy  system,  i.e.,  a  system  that  has  undergone  many  modifications  through  years  of 
maintenance,  and  explains  how  the  RET  helps  you  overcome  those  problems.  Section  4.1 
describes  the  use  of  the  Packager  component  of  the  RET  Section  4.2  discusses  the  use  of 
the  Transformer  component  and  explains  some  of  the  issues  involved  in  translating  cer¬ 
tain  language  featiires. 

4.1  DEVELOPING  PROGRAM  STRUCTURE  USING  THE  PACKAGER 

You  may  peruse  the  FORTRAN  system  by  navigating  through  several  views.  You 
may  find  yourself  overwhelmed  with  information  when  you  initially  confi-ont  an  entire 
legacy  system  if  it  is  very  large.  One  way  to  reduce  the  amount  of  information  that  you 
must  comprehend  is  to  examine  only  the  large-scale  constructs  of  the  program.  For  exam¬ 
ple,  you  might  first  be  interested  in  understanding  the  relationships  between  the  modules 
that  comprise  the  system. 

To  discover  the  modular  structure  of  the  FORTRAN  system,  you  may  direct  the 
Packager  component  of  the  RET  prototype  to  cluster  subprograms  into  groups  that  will 
eventually  become  Ada  packages.  The  Packager  iteratively  applies  clustering  techniques 
described  by  Hutchens  (Ref.  9)  and  Muller  (Ref.  10)  to  analyze  the  FORTRAN  system  and 
group  subprograms  based  upon  calling  relationships  and  patterns  of  data  usage,  mea¬ 
sured  in  terms  of  data  bindings. 

During  the  analysis,  you  may  gain  a  better  understanding  of  each  subprogram’s 
purpose  and  why  subprograms  are  grouped  as  they  are.  The  Packager  invites  you  to  ex¬ 
plore  the  most  recently  clustered  modules  after  each  iteration.  The  RET  prototype  orga¬ 
nizes  the  subprograms  and  helps  you  explore  groups  of  related  subprograms  that  are,  in 
the  sense  of  the  clustering  criteria,  more  closely  related  than  others. 
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4.1.1  De£baiitions 


The  Packager  uses  data  bindings  to  cluster  some  modules.  Adata  binding  is  a  tuple 
(p,  X,  q)  where  p  and  q  are  subprograms  that  reference  data  object  x.  The  RET  only  counts 
data  bindings  in  which  the  data  object  is  written  by  one  subprogram  and  read  by  the  other. 

The  RET  computes  the  Interconnection  Strength  (IS)  and  the  Common  Client  and 
Supplier  (CS)  sets  based  upon  the  actual  data  bindings.  The  IS  is  the  number  of  data  bind¬ 
ings  between  two  subprograms.  Wherever  the  RET  prototype  displays  the  IS  between  two 
subprograms,  it  adds  one  to  it  if  either  of  the  two  subprograms  calls  the  other. 

The  common  chents  of  a  group  of  subprograms  are  those  subprograms  which  read 
data  that  is  written  by  every  subprogram  in  the  group.  The  common  suppliers  of  a  group  of 
subprograms  are  those  subprograms  that  provide  data  to  every  subprogram  in  the  group. 

Clustering  produces  a  tree  of  modules.  The  root  module  represents  the  Ada  library, 
intermediate  modules  represent  packages,  and  the  leaves  represent  subprograms.  The 
root  is  defined  to  be  at  level  zero  and  its  children  are  at  level  one. 

The  Packager  displays  one  graph  for  the  Ada  hbrary,  and  one  for  each  potential 
package.  The  Packager  graph  is  an  abstraction  that  presents  relationships  among  pro¬ 
gram  modtdes,  such  as  data  objects  shared  between  them.  Nodes  in  the  graph  represent 
nested  modules,  i.e.,  packages  or  subprograms,  and  the  edges  depict  data  binding  rela¬ 
tionships  between  them. 

There  is  exactly  one  graph  associated  with  any  given  nonleaf  modxile,  M,  in  the 
tree;  we  refer  to  it  as  the  graph  of  M.  The  nodes  in  that  graph  correspond  to  the  direct  chil¬ 
dren  of  M  in  the  tree.  The  edges  between  the  nodes  in  the  graph  depict  the  data  binding 
relationships  between  the  corresponding  packages  or  subprograms.  We  use  the  term 
package  structure  to  refer  to  both  the  tree  and  its  graphs.  For  simpHcity,  we  refer  to  nodes 
as  packages  or  subprograms  or,  when  the  distinction  is  unnecessary,  as  modules. 

The  graph  in  Figure  4  shows  one  subprogram  (FCRjOUTPUT),  five  packages 
(fcrjdf,  fcr_dr,  main,  modes,  and  dead  code),  nine  edges,  and  nine  edge  labels.  An  edge 
between  two  modules  indicates  that  they  share  data  bindings.  An  edge  between  a  package 
and  another  module,  M,  indicates  that  at  least  one  subprogram  in  the  package  shares  data 
bindings  with  M.  The  edge  labels  list  the  data  objects  that  comprise  the  bindings  or  show 
the  subprograms  in  the  package  that  are  involved  in  the  data  bindings. 
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i  RET  Main  Window 


Figure  4  The  Packager  View 


The  edge  labels  in  Figure  4  provide  information  about  the  variables  shared  be¬ 
tween  the  modules.  The  edge  label  between  packages  modes  and  fcr_dr  lists  the  variable 
names  involved  in  the  data  bindings  between  them.  This  label  lists  one  variable  (IRSQ) 
that  is  read  and  written  by  both  packages,  one  variable  (MDR32J)  that  is  read  by  modes 
and  written  by  fcrjdr,  and  ten  variables  that  are  read  hy  for _dr  and  written  by  modes. 

The  edge  label  between  FCRjOUTPUT  and  fcr_dr  shows  that  there  is  one  data 
binding  between  FCRjOUTPUT  and  each  of  seven  subprograms  nested  directly  under 
fcr_dr,  and  one  data  binding  between  FCRJOUTPUT  and  each  of  three  subprograms 
(FCR_AD0,  FCR_DR003,  and  FCR_DR008)  nested  directly  under  fcr_ad,  which  is  nested 
directly  under  fcr_dr. 

The  label  between  dead  code  and  modes  is  similar,  except  that  it  is  between  two 
packages.  The  label  on  the  edge  between  FCRJOUTPUT  and  modes  shows  the  total  num¬ 
ber  of  variables  (1)  shared  between  them. 

4.1.2  Creating  a  Package  Structure 

Initially,  every  subprogram  is  at  level  one  in  the  package  structure  and  appears  in 
the  level-zero  graph.  The  edges  in  the  graph  2U'e  not  shown  by  default  because  there  are 
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generally  too  many  of  them,  but  you  may  view  (or  hide)  the  edges  adjacent  to  any  module 
by  choosing  the  appropriate  menu  option.  You  may  view  the  original  source  code 
associated  with  any  module  by  selecting  it  with  the  mouse.  You  may  select  specific  subpro¬ 
grams  to  be  grouped  together,  or  apply  an  automatic  clustering  algorithm. 

The  RET  provides  two  clustering  metrics  and  each  can  be  defined  as  a  function  of 
two  subprograms.  The  Common  Clients  and  Suppliers  (CS)  metric  counts  the  number  of 
other  subprograms  that  provide  data  to,  or  accept  data  from  two  subprograms.  This  met¬ 
ric  is  useful  for  locating  and  grouping  utility  or  library  routines,  such  as  math  or  I/O  rou¬ 
tines.  The  Interconnection  Strength  (IS)  metric  counts  the  number  of  shared  data  items 
that  two  subprograms  reference.  This  metric  is  useful  in  grouping  subprograms  that  ma¬ 
nipulate  common  global  variables  or  exchange  data  by  parameters. 

The  automatic  clustering  process  is  iterative.  To  begin  clustering,  we  recommend 
that  you  direct  the  RET  prototype  to  perform  one  clustering  iteration  using  the  CS  metric. 
We  call  this  strategy  CS-clustering.  It  tends  to  group  modules  that  receive  data  fi'om,  or 
pass  data  to  the  same  modules.  The  Packager  computes  the  common  chent  and  supplier 
sets  for  each  pair  of  level-one  modules  and  identifies  the  group  of  modules  that  share  the 
greatest  number  of  clients  or  suppliers.  It  then  modifies  the  package  structure  to  combine 
the  modules  in  this  group. 

We  recommend  that  you  perform  CS-clustering  one  iteration  at  a  time  for  several 
reasons.  CS-clustering  only  takes  a  few  iterations  to  identify  many  of  the  utihty  subpro¬ 
grams,  and  the  RET  prototype  relies  on  you  to  determine  when  to  stop  clustering.  The 
RET  also  relies  on  you  to  manually  add  or  remove  subprograms  because  the  heuristic 
strategy  is  imperfect. 

Once  you  decide  that  CS-clustering  is  not  uncovering  any  new  utility  subprograms, 
you  may  choose  to  initiate  IS-clustering.  With  this  strategy,  the  Packager  computes  the  in¬ 
terconnection  strength  between  each  pair  of  level-one  modules;  determines  the  maximum 
IS,  denoted  ISmax,  among  all  the  modules;  and  groups  those  modules  that  are  involved  in  an 
ISmax  relation.  You  may  perform  IS-clustering  one  iteration  at  a  time,  but  it  is  faster  to  direct 
the  Packager  to  iterate  imtil  only  one  level-one  module  remains  in  the  level-zero  graph,  i.e., 
all  subprograms  have  been  clustered  into  (possibly  nested)  packages. 

We  recommend  that  you  employ  CS-clustering  before  IS-clustering  because  the  for¬ 
mer  identifies  groups  of  utihty  subprograms  that  are  not  recognized  by  the  latter.  If  IS- 
clustering  combined  a  utility  subprogram  with  other  subprograms,  the  CS  metrics  for  the 


17 


resulting  package  would  be  different  from  the  utility  subprogram’s  CS  metrics  and  the 
utility  would  be  less  likely  to  combine  with  other  utilities  during  CS-clustering. 

With  either  clustering  strategy,  when  the  Packager  groups  a  set  of  modules,  it 
creates  a  new  level-one  package  and  moves  the  grouped  modules  to  level  two,  i.e.,  Tinder 
the  new  package.  Edges  appear  in  the  level-zero  graph  between  the  new  package  and  any 
level-one  modules  that  share  data  bindings  with  it. 

With  either  strategy,  you  may  inspect  and/or  alter  the  package  structure  after  each 
Packager  iteration.  Alternatively,  you  may  direct  the  Packager  to  iterate  until  every  mod¬ 
ule  has  been  included  in  some  package,  automatically  providing  an  approximation  to  a 
reasonable  package  structure.  You  should  verify  the  resulting  package  structure  because 
you  may  wish  to  modify  the  structure  through  the  views  to  obtain  an  appropriate  group¬ 
ing.  The  information  provided  to  you  by  the  Packager  facihtates  this  analysis,  and  editing 
operations  allow  you  to  easily  change  the  structure. 

The  clustering  strategies  described  above  produce  a  hierarchical  organization  of 
packages;  there  are  packages  nested  within  other  packages.  Although  the  RET  prototype 
can  generate  Ada  code  corresponding  to  a  hierarchical  nesting  structure,  it  may  be  easier 
to  maintain  Ada  code  which  consists  of  smaller  library  unit  packages  because  such  designs 
tend  to  discourage  redimdancy  and  strengthen  encapsulation.  You  may  wish  to  ’’flatten”  the 
generated  package  structure,  i.e.,  increase  its  width  and  decrease  its  depth.  The  RET  proto¬ 
type  generates  with  context  clauses  for  any  package  that  references  a  library  unit. 

The  Packager  tries  to  prevent  the  package  structure  from  becoming  unnecessarily 
deep  by  maintaining  a  threshold  on  the  package  size.  When  package  A  is  to  be  moved  into 
package  B  such  that  A  would  be  nested  within  B,  the  Packager  checks  the  number  of  mod¬ 
ules  in  package  A.  If  it  is  below  the  threshold  that  you  have  specified,  then  the  modules 
in  A  are  moved  to  B  and  the  package  A  is  eliminated. 

This  somewhat  arbitrary  heuristic  is  only  useful  for  preventing  the  formation  of 
many  tiny  packages  and,  in  practice,  the  threshold  must  be  set  quite  low.  The  threshold 
is  set  to  five  in  the  RET  prototype.  You  may  wish  to  intervene  during  clustering  and  edit 
the  package  structure  as  it  evolves  in  order  to  reduce  nesting. 

4.1.3  Editing  the  Package  Structure 

Packager  graphs  are  interactive  displays.  You  may  open  pop-up  menus  by  position¬ 
ing  the  mouse  cursor  over  a  module,  an  edge,  the  backgroimd,  or  the  window  title  and 
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clicking  the  right  mouse  button.  The  resulting  pop-up  menu  shows  commands  for  the 
module,  edge,  backgroimd,  or  window.  We  refer  to  this  below  as  issuing  a  module,  edge, 
background,  or  window  command.  The  RET  provides  commands  for  navigating,  browsing, 
and  editing  the  package  structure. 

Navigation  commands  allow  you  to  display  different  graphs  by  clicking  on  a  pack¬ 
age  or  the  background.  The  descend  package  command  causes  the  RET  to  display  a  pack¬ 
age’s  graph.  The  ascend  background  command  causes  the  RET  to  display  the  parent 
package’s  graph. 

Browsing  commands  alter  the  Packager  display  without  changing  the  generated 
package  structure.  The  RET  prototype  provides  browsing  commands  on  the  module,  edge, 
background,  and  window  pop-up  menus. 

•  Module  commands  allow  you  to  select  or  deselect  individual  modules  or  mod¬ 
ules  in  a  region,  show  or  hide  individual  or  selected  modules,  drag  and  reshape 
modules,  and  show  FORTRAN  and/or  Ada  source  code. 

•  Edge  commands  allow  you  to  select  or  deselect  individual  edges,  show  or  hide 
individual  or  selected  edges,  and  show  global  or  local  bindings  (or  both)  on  edges. 

•  Background  commands  allow  you  to  arrange  modules  in  a  circle  or  grid,  and 
refresh,  scroll,  and  zoom  the  display. 

•  Window  commands  allow  you  to  move,  refresh,  hide,  reshape,  and  close  the 
Packager  display. 

Editing  commands  allow  you  to  edit  module  names  and  alter  the  Ada  package 
structure.  You  may  move  a  module  from  the  current  graph  to  another  package  in  that 
graph  via  the  push  command,  or  to  the  parent  package’s  graph  via  the  pop  command.  The 
pop-to-top  command  moves  a  package  all  the  way  up  to  the  Ada  hbrary  level.  The  disperse 
command  eliminates  a  package  from  the  current  graph  and  moves  all  of  the  modules  that 
were  nested  in  it  up  one  level  in  the  graph.  The  RET  maintains  the  edges  between  the 
packages  and  subprograms  as  you  change  the  package  structure. 

You  can  assign  navigation  and  source  code  display  commands  to  the  middle  mouse 
button  to  reduce  the  number  of  mouse  or  keyboard  events  required  to  effect  a  command. 
We  have  formd  this  to  be  very  convenient  when  working  with  a  large  system.  The  left 
mouse  button  is  always  assigned  to  the  select  and  deselect  commands.  The  right  mouse 
button  is  always  assigned  to  the  pop-up-menu  command. 
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4.1.4  Distributing  Data  Items 

The  Packager  automatically  distributes  global  data  items  among  the  modules  of 
the  package  structure.  The  algorithm  reduces  each  data  item  scope  while  maintaining  its 
visibihty  as  needed.  It  is  based  upon  the  following  criteria. 

•  If  a  data  item  is  used  only  by  subprograms  in  a  single  package,  the  data  item 
declaration  is  placed  in  the  package  body. 

•  If  a  data  item  is  used  by  subprograms  in  more  than  one  package,  but  most  often 
by  subprograms  in  a  particular  package,  the  data  item  declaration  is  placed  in 
that  package  specification.  Other  packages  that  use  the  data  item  specify  a 
context  clause  for  the  package. 

•  A  new  package  is  created  for  each  common  block  with  remaining  tmdistributed 
data  items.  These  data  items  are  used  by  subprograms  in  more  than  one  pack¬ 
age,  with  no  package  clearly  using  them  more  often.  The  data  item  declara¬ 
tions  are  placed  in  the  new  package  specifications,  and  other  packages  that  use 
the  data  items  specify  context  clauses  for  the  new  packages. 

The  data  object  distribution  algorithm  is  most  effective  when  there  are  many  data 
objects  declared  in  one  module,  such  as  a  common  block,  that  are  referenced  by  few  other 
modules.  Embedded  systems  may  use  common  blocks  to  map  variables  to  specific  memory 
locations.  Warning;  distributing  these  variables  among  the  packages  so  as  to  re¬ 
duce  the  scope  of  their  declarations  would  disperse  the  specification  of  the  map¬ 
ping  throughout  the  code  and  make  it  more  difficult  to  change  the  mapping. 

The  RET  protot3npe  analyzes  FORTRAN  EQUIVALENCE  statements  to  check  for 
memory-mapped  common  blocks.  The  RET  only  distributes  the  variables  from  common 
blocks  that  it  determines  not  to  be  memory-mapped.  The  RET  prompts  you  to  accept  or 
override  it’s  choice  before  it  distributes  any  variables. 


4.2  TRANSLATING  PROGRAM  STATEMENTS 

Once  you  have  constructed  and  refined  the  package  structiire  of  the  Ada  system 
and  placed  the  variable  declarations  where  desired,  the  Transformer  component  of  the 
RET  prototype  helps  with  micro  restructuring  by  translating  individual  statements  firom 
the  source  to  the  target  programming  language.  You  may  inspect  the  FORTRAN  Source 
Code  Listing  view  for  any  module  and  select  statements  with  the  mouse.  The  RET  trans¬ 
lates  them  to  Ada  and  inserts  them  into  the  Ada  ASG.  If  you  have  renamed  variable  decla¬ 
rations,  then  the  RET  prototype  generates  references  to  those  variables. 
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The  RET  prototype  generates  Ada  code  for  the  package  structxire  that  the  Packager 
produces.  First  the  RET  creates  a  skeleton  of  the  Ada  system,  and  then  it  transforms  indi¬ 
vidual  statements.  The  skeleton  Ada  code  comprises  package  and  subprogram  specifica¬ 
tions  and  bodies  that  may  include  variable  and  constant  declarations.  The  subprogram 
bodies  include  a  single  null  statement.  The  RET  generates  subunits  at  your  option.  The 
RET  also  generates  a  type  package  that  defines  all  of  the  types  and  subtypes  referenced  in 
the  variable  declarations.  The  type  package  declares  Ada  types  that  correspond  closely  with 
FORTRAN  types,  although  an  exact  mapping  is  not  generally  available  as  explained  below. 

Translating  FORTRAN  statements  that  map  readily  onto  Ada  language  features 
is  straightforward.  For  example,  the  RET  prototype  can  easily  translate  Block  IF  and 
DO! END  DO  statements  into  Ada  IF  and  LOOP  statements,  respectively,  because  the  se¬ 
mantics  are  consistent  between  the  languages.  The  fact  that  the  control  variable  of  a 
FORTRAN  DO  statement  remains  defined  after  the  loop  is  a  nxiisance. 

There  are  FORTRAN  constructs  for  which  the  mapping  to  Ada  is  not  obvious  or  for 
which  there  is  a  choice  of  translations.  We  have  found  several  sources  of  difficulty  in  trans¬ 
forming  individual  statements  in  such  a  way  as  to  avoid  propagating  imdesirable  FORTRAN 
constructs  while  taking  advantage  of  Ada  language  features  not  present  in  FORTRAN.  They 
include  the  use  of  unstructured  control  constructs,  the  general  lack  of  correspondence  be¬ 
tween  lan^age  features  and,  in  particular,  differences  in  the  data  type  systems. 

4.2.1  Unstructured  Control  Constructs 

Some  FORTRAN  code  contains  unstructured  control  forms,  defined  simply  as 
branches  into  or  out  of  loops  or  decisions.  While  such  forms  do  not  always  impede  mainte¬ 
nance,  they  usually  make  the  code  harder  to  understand  and  modify.  Unstructured  con¬ 
trol  forms  exist  in  code  that  was  written  before  the  benefits  of  structured  programming 
were  widely  acknowledged. 

Some  FORTRAN  language  features  encourage  unstructured  designs.  Arithmetic 
IF  statements  cause  control  to  be  transferred  to  any  one  of  three  locations  based  on  a  test. 
Logical  IF  statements  are  only  problematic  when  they  are  used  with  GOTO  statements. 
VAX  FORTRAN  extended  ranges  (in  DO  loops)  are  egregious  examples  of  unstructm-ed 
constructs  that  might  effectively  confound  maintenance  programmers.  The  RET  proto¬ 
type  assumes  that  you  have  processed  the  FORTRAN  code  with  SPAG  (Ref.  3),  a  commer¬ 
cial  control  flow  restructuring  tool,  to  eliminate  control  structures  that  are  difficult  to 
translate.  The  tool  removes  most  of  the  objectionable  constructs. 
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4.2.2  Lan^age  Features 

The  RET  prototype  generates  code  for  Ada  language  features  that  have  no  counter¬ 
part  in  FORTRAN,  but  which  produce  programs  that  are  substantially  easier  to  maintain. 
For  example,  the  RET  does  take  advantage  of  Ada  packages  because  we  feel  that  they  are 
useful  for  encapsulating  code  and  help  to  reduce  the  ripple  effect  of  modifications.  On  the 
other  hand,  the  RET  prototype  does  not  generate  Ada  code  which  uses  exceptions  because 
we  believe  that  they  make  the  code  more  difficult  to  xmderstand  and,  except  in  select  situ¬ 
ations,  are  of  limited  value. 

4.2.3  Data  Type  Systems 

FORTRAN  has  fewer  types  than  Ada  and  it  allows  implicit  conversions  which  must 
be  explicit  in  Ada.  Data  types  that  seem  to  serve  the  same  purpose  may  have  different 
implementations  across  languages.  The  application  may  even  rely  upon  compiler  imple¬ 
mentation  details  or  undocumented  language  features.  This  fact  is  often  an  important 
consideration  when  translating  embedded  systems.  The  ASRET  Final  Report,  Vol.  I 
(Ref.  1)  provides  details  on  how  the  RET  prototype  converts  data  t3T)es. 
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5. 


RET  REFERENCE 


This  section  provides  reference  information  for  the  RET  prototype  user  interface. 
It  assumes  that  you  know  how  to  start  the  prototype.  If  you  don’t,  ask  the  person  who 
installed  it  because  several  options  may  be  available.  If  you  are  responsible  for  instalHng 
the  RET  protot3rpe,  see  The  Avionics  Software  Reengineering  Technology  (ASRET)  Project 
Final  Report,  Volume  I,  Project  Sinnmary,  Account,  and  Results  (Ref.  1).  Section  8  of 
Vol.  I,  RET  PROTOTYPE  PLATFORM,  provides  information  on  running  the  RET  proto¬ 
type  under  GNU  Emacs  (Ref.  11).  You  may  alternatively  wish  to  create  an  executable  to 
run  stand-alone,  i.e.,  without  Emacs. 

The  RET  prototype  assumes  that  the  FORTRAN  source  code  was  processed  by 
SPAG  (Ref.  3)  and  REFINE/FORTRAN  (Ref.  12)  as  described  in  the  ASRET  Final  Report 
(Ref.  1).  The  input  to  the  RET  prototype  (Section  5.1)  is  the  analysis  file  created  by  RE¬ 
FINE/FORTRAN. 

The  reference  information  in  this  section  is  organized  around  the  RET  prototype 
views.  Each  section  explains  how  to  operate  a  single  view  (Table  2).  The  reference  as¬ 
sumes  that  you  are  familiar  with  common  Graphical  User  Interface  (GUI)  concepts  such 
as  windows,  the  mouse  ciusor  and  buttons,  and  pull-down  and  pop-up  menus.  The  discus¬ 
sions  on  the  menu  options  listed  in  Table  3  through  Table  25  e^lain  only  those  featrues 
of  the  RET  prototype  that  are  not  ubiquitous  in  GUIs. 


Table  2  RET  Reference  Directory 


SECTION 

DESCRIBES 

5.1 

RET  main  window 

5.2 

Packager  view 

5.3 

Dataflow  Diagram 

5.4 

Call  Diagram 

5.5 

Declaration  Diagram 

5.6 

FORTRAN  Source  Code  Listing 

5.7 

Ada  Source  Code  Listing 
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5.1  RET  MAIN  WINDOW 

The  Main  Window  in  Figure  5  shows  the  title  area  at  the  top,  the  command  area  be¬ 
neath  it,  and  the  workspace  with  three  views  and  one  pop-up  window.  The  Packager  view  is 
partially  occluded  by  the  PACKAGE  VARIABLES  pop-up  window  and  the  Declaration  Dia¬ 
gram  (DED)  and  Call  Diagram  (CD)  views.  The  command  area  lists  the  Analysis,  \Tews, 
and  Reshape  pull-down  menus.  You  may  activate  the  pull-down  menus  by  cHcking  on  them 
with,  and  holding  down  the  left  mouse  button,  an  operation  referred  to  as  “left-cHcking.” 

To  begin  an  analysis,  pull  down  the  Analysis  menu  shown  in  Figure  6  by  left-clicking 
on  Analysis  in  the  command  area.  While  holding  down  the  left  mouse  button,  drag  the  cur¬ 
sor  over  the  Perform  menu  option,  and  then  release  the  left  mouse  button.  The  RET  proto¬ 
type  pops  up  a  window  that  prompts  for  the  REFINE/FORTRAN  analysis  file.  You  may  edit 
the  file  name  in  this  window  as  explained  in  the  INTERVISTA  User’s  Manual  (Ref.  13). 

After  you  enter  the  file  name,  the  RET  prototype  reads  the  analysis  file  and  per¬ 
forms  initialization  processing.  This  may  take  up  to  an  hour  for  a  system  with  about 
twenty  thousand  lines  of  code.  While  the  RET  is  processing  the  analysis  file,  it  will  print 
messages  to  the  Emacs  *REFINE*  buffer.  When  initialization  is  complete,  the  RET  will 
print  the  message  “Analysis  Complete.” 
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Figure  6  Analysis  Pull-Down  Menu 


The  Reuse  R/F,  Clear,  Dump,  and  Load  menu  options  shown  in  Figvire  6  are  no 
longer  in  use,  but  remain  in  the  pull-down  menu  because  future  versions  of  the  RET  proto- 
t3^e  may  use  them. 

You  may  now  show  the  DED,  CD,  or  Packager  views  by  selecting  the  Show  DED, 
Show  CD,  or  Show  Packager  menu  options,  respectively,  shown  in  Figure  7.  The  RET 
prototype  can  not  produce  a  DFD  until  it  generates  Ada  source  code,  so  don’t  select  the 
Show  DFD  or  Show  Ada  Source  options  at  this  time.  You  may  select  the  Regenerate 
options  at  any  time  to  cause  the  RET  protot5rpe  to  recreate  one  of  the  views.  You  may  load 
a  DFD  or  Packager  view  if  you  have  previously  saved  one  by  selecting  the  Load  DFD  or 
Load  Packager  option. 

The  Reshape  pull-down  menu  in  Figure  8  provides  options  to  change  the  size  and 
position  of  the  “current”  view.  Only  one  view  at  a  time  is  designated  as  the  current  view. 
The  title  of  the  cxirrent  view  is  enclosed  by  “»>”  and  ”«<”  as  shown  in  Figure  5,  wherein 
the  Packager  view  (the  window  entitled  “Packager  -  library”)  is  current.  The  DED  and  CD 
views  in  Figure  5  were  reshaped  via  the  Lower  Left  and  Lower  Right  menu  options, 
respectively. 
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RET  Main  Window 


Analysis  Reshape _ 

Show  DED 
Regenerate  DED 
Show  CD 
Regenerate  CD 
Show  FORTRAN  Source 
Show  Ada  Source 
Load  DFD 
Show  DFD 
Regenerate  DFD 
Load  Packager 
Show  Packager 
Regenerate  Packager 


Figure  7  Views  Pull-Down  Menu 


RET  Main  Window 


Figure  8  Reshape  Pull-Down  Menu 
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5.2  PACKAGER  VIEW 


Figure  9  is  a  duplicate  of  Figure  4  and  is  explained  in  Section  4.1.1.  Figure  10 
shows  a  Packager  view  with  Call  edges  that  depict  subprogram  calls.  The  edge  on  the  left 
indicates  that  subprogram  RLTJNPUT  calls  RLT_F066_IN  and  RLT_REF_IN,  both  of 
which  are  declared  in  package  rlt_in.  The  edge  on  the  right  shows,  in  a  different  format, 
that  RLT_OUTPUT  calls  RLT_RLTADO  and  RLT_RL001_OUT.  The  RET  protot3^e  pro¬ 
vides  the  second  format  because  the  first  does  not  distinguish  individual  subprogram  calls 
when  the  edge  appears  between  two  packages.  You  may  alternate  between  the  two  for¬ 
mats  by  middle-clicking  on  the  edge  label. 

Figure  11  shows  a  Packager  view  conteuning  five  intrinsic  functions  generated  by 
the  RET  protot3^e  and  the  corresponding  generated  Ada  Source  Code  Listing  for  the 
INTRINSICS  package.  The  formal  parameter  types  and  the  return  types  are  given  in  the 
nodes. 


Figure  12  shows  a  Packager  view  containing  four  external  subprograms  generated 
by  the  RET  prototype  and  the  corresponding  generated  Ada  Source  Code  Listing  for  the  EX¬ 
TERNALS  package.  The  formal  parameter  types  and  the  return  types  (for  the  function)  are 
given  in  the  nodes.  Note  that  external  subprograms  may  be  functions  or  procedures. 


Figure  9  Packager  Yiew  With  Data  Binding  Edges 
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Figure  10  Packager  View  With  Call  Edges 


RET  Main  Window 


Analysis  Views  Reshape 


Packaeer-  INT 


Ada  Source*' 


package  body  IMTRINSICS  is 
function  FLOATJ  (  P_l:  in  out  INT_4) 
return  BCAL_4 
is  begin  null; 
end  FLOAIJ; 

function  ABS_X  (  P_l:  in  out  RL»L_4) 
return  Iti:i^_4 
is  begin  null; 
end  ABS_X; 

function  JITIX  (  P^l:  in  out  P£AL_4) 
return  IHT_4 
is  begin  null; 
end  JXrzX; 
function  IZSHFT 

(  P_l;  in  out  I1IT_2; 

P”2;  in  out  Iin:”2) 
return  zxr_2 
is  begin  null; 
end  IISHFT; 
function  JZSHFT 

(  P_l:  in  out  lirr^4; 

p“2:  in  out  1KT“4) 
return  zm'_4 
is  begin  null; 
end  JISBFT: 
begin  null; 
end  ZNIEUMSICS; 

package  IBQtZNSZCS  is 

function  PLObTJ  (  P_l:  in  out  ZKX_4) 
return  AZbL_4 ; 

function  ABS_X  (  P_l;  in  out  RrAL._4) 
return  KCbL_4; 

function  JirnC  (  P_1 :  in  out  KEALj4) 
return  ZKr_4; 
function  ZlSSn 

(  P_l:  in  out  I»T_2; 

P_2:  in  out  INT_2) 
return  1KT_2; 
function  JZSRFT 

(  P_l;  in  out  IST_4; 

P_2;  in  out  ZST_4) 
return  Zlir_4; 
end  ZZnitlKSZCS; 


Figure  11  Packager  and  Source  Code  Views  of  Intrinsic  Functions 
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RET  Main  Window' 


Analysis  Views  Reshape 


Packager  -  EXl 


package  body  E3aEIUUU.S  ia 
pcocedure  K&PKCK 

(  P_l;  in  out  81TSJ2; 

P  2:  xn  out  BnS_I6. 
p'3:  in  out  8ITSJ2) 
ia  begin  null; 
end  X&PSCa: 

procedure  SET  (  P  1:  in  out  BCOLEAN]  la  begin 
null; 
end  SET. 

procedure  RESET 

(  P_I ;  in  out  BODLEAM) 
ia  begin  null; 
end  RESET; 
function  IS  SET 

(  p_l;  in  out  BOOLEMl)  return  BOOLEAN 
ia  begin  null; 
end  IS_SEX; 
begin  null; 
end  EglERNALS. 

package  EXTERNALS  ia 
procedure  WAPSEN 

(  P_l:  in  out  Brrs_32. 

P  2:  in  out  BITS  16; 
p"3i  in  out  Brrs_32); 
procedure  SET  (  P_1 :  in  out  BOOLEAN) ; 
procedure  RESET 

(  P_l:  in  out  BOOLEAN); 
function  IS  SET 

(PI:  in'out  BOOLEAN)  return  BOOLEAN; 
end  EXTERNALS. 


Figure  12  Packager  and  Source  Code  Views  of  External  Subprograms 


Table  3  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  a  package 
node  in  the  Packager  view.  The  Drag  options  allow  you  to  reposition  a  single  node  (also 
called  an  icon),  all  selected  nodes,  or  all  nodes  that  have  an  edge  to  the  current  node  by 
left-clicking.  Reshape  lets  you  change  the  size  of  a  node.  Generate  Statements  causes 
the  RET  to  transform  the  FORTRAN  code  for  the  current  node  to  Ada.  Write  Files  creates 
ASCII  files  for  the  current  node,  and  Parse  Files  parses  them  without  analyzing  them. 
Edit  Name  lets  you  rename  a  node.  Edit  Spec  and  Body  open  Emacs  buffers  for  the 
specification  and  body  files,  respectively.  (De)Select  Icon  changes  the  reverse-video  sta¬ 
tus  of  a  node,  making  it  (in)sensitive  to  other  menu  options  that  operate  on  selected  nodes. 


29 


Tables  Packager  Package  Pop-Up  Menu 


PAK;  PACKAGE 

Drag 

Drag  Selected  Icons 
Drag  Connected  Icons 
Reshape 

Generate  Statements 
Write  Files 
Parse  Files 
Edit  Name 
Edit  Spec 
Edit  Body 
Select  Icon 
Deselect  Icon 
Mouse  Left = Select 
Mouse  Lefts  Drag 

Mouse  Middles  View  FORTRAN  Code 

Mouse  Middle  s  View  FORTRAN/Ada  Code 

Mouse  Middle  s  View  Ada  Code 

Mouse  Middle = Navigate 

Mouse  Middle  =  Reshape 

Hide  Icon 

Hide  Edges 

Show  Edges 

Draw  Edges  Manually 

Draw  Edges  Automatically 

Draw  Edges  as  Straight  Lines 

Show  Data  Bindings 

Show  Call  Relations 

Show  Ada  Source  Code 

Show  Package  Variables 

Set  Subprograms  Separate  False 

Push  Selected  Icons  Into  Package 

Push  Into  Package 

Pop  Out  of  Package 

Pop  to  Library 

Disperse 

Delete 

Descend 

PUP 

Inspect 

Abort 
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The  Mouse  Left  (Middle)  options  assign  the  specified  functions  to  the  left 
(middle)  mouse  buttons.  The  Navigate  function  implies  Ascend  (Table  6)  and  Descend. 
The  other  functions  are  explicitly  listed  as  menu  options.  Hide  Icon  (Edges)  causes  the 
objects  to  disappear.  Show  Edges  causes  all  hidden  edges  to  reappear.  The  Draw  Edges 
options  provide  a  means  to  respecify  the  layout  of  the  edges.  Show  Data  Bindings  and 
Show  Call  Relations  alternate  the  t5rpes  of  edges  that  are  shown.  Show  Package  Vari¬ 
ables  pops  up  a  window  that  lists  the  variables  in  the  package.  Set  Subprograms  Sepa¬ 
rate  True  (False)  (re)sets  flags  that  cause  the  Ada  code  for  the  subprograms  to  be 
generated  as  subunits.  The  Push  and  Pop  options  allow  you  to  move  nodes  down  and  up, 
respectively,  in  the  package  hierarchy.  Disperse  dissolves  the  package  and  promotes  its 
nested  nodes  to  the  current  graph.  Descend  causes  the  package’s  graph  to  replace  the 
current  graph.  PUP  and  Inspect  are  debugging  options.  Abort  closes  the  menu  without 
taking  any  action. 

Table  4  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  a  subpro¬ 
gram  node  in  the  Packager  view.  The  Drag  options  allow  you  to  reposition  a  single  node, 
all  selected  nodes,  or  all  nodes  that  have  an  edge  to  the  current  node.  After  choosing  the 
Drag  option  for  a  node,  move  the  mouse  to  a  clear  area  on  the  background  while  holding 
down  the  left  mouse  button  and  release  it  at  the  desired  position.  Reshape  lets  you 
change  the  size  and  shape  of  a  node.  Generate  Statements  causes  the  RET  to  transform 
the  FORTRAN  code  for  the  cmrent  node  to  Ada.  Write  Files  creates  ASCII  files  for  the 
current  node,  and  Parse  Files  parses  them  without  analyzing  them.  Edit  Name  lets  you 
rename  a  node.  Edit  Spec  and  Body  open  Emacs  buffers  for  the  specification  and  body 
files,  respectively.  (De)Select  Icon  changes  the  reverse-video  status  of  a  node,  making  it 
(in)sensitive  to  other  menu  options  that  operate  on  selected  nodes. 

The  Mouse  Left  (Middle)  options  assign  the  specified  functions  to  the  left 
(middle)  mouse  buttons.  The  Navigate  function  implies  Ascend  (Table  6)  and  Descend. 
The  other  functions  are  explicitly  listed  as  menu  options.  Hide  Icon  (Edges)  causes  the 
objects  to  disappear.  Show  Edges  causes  all  hidden  edges  to  reappear.  The  Draw  Edges 
options  provide  the  means  to  respecify  the  layout  of  the  edges.  Show  Data  Bindings  and 
Show  Call  Relations  alter  the  types  of  edges  that  are  shown.  The  Push  and  Pop  options 
allow  you  to  move  nodes  down  and  up,  respectively,  in  the  package  hierarchy.  Disperse 
dissolves  the  package  and  promotes  its  nested  nodes  to  the  current  graph.  Descend 
causes  the  package’s  graph  to  replace  the  current  graph.  PUP  and  Inspect  are  debugging 
options.  Abort  closes  the  menu  without  taking  any  action. 
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Table  4  Packager  Subprogram  Pop-Up  Menu 


PAK:  SUBPROGRAM 

Drag 

Drag  Selected  Icons 
Drag  Connected  Icons 
Reshape 

Generate  Statements 
Write  Files 
Parse  Files 
Edit  Name 
Edit  Spec 
Edit  Body 
Select  Icon 
Deselect  Icon 
Mouse  Left = Select 
Mouse  Left = Drag 

Mouse  Middle  =  View  FORTRAN  Code 

Mouse  Middle = View  FORTRAN/Ada  Code 

Mouse  Middle = View  Ada  Code 

Mouse  Middle = Navigate 

Mouse  Middle = Reshape 

Hide  Icon 

Hide  Edges 

Show  Edges 

Draw  Edges  Manually 

Draw  Edges  Automatically 

Draw  Edges  as  Straight  Lines 

Show  Data  Bindings 

Show  Call  Relations 

Show  FORTRAN  Source  Code 

Show  FORTRAN/Ada  Source  Code 

Show  Ada  Source  Code 

Push  Into  Package 

Pop  Out  of  Package 

Pop  to  Library 

Disperse 

Delete 

Descend 

PUP 

Inspect 

Abort 
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Table  5  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  a  data 
bindings  edge  label  in  the  Packager  view.  The  Show  Call  and  Show  Binding  options 
change  the  t5rpe  of  edge  label  that  the  Packager  displays  on  call  and  data  binding  edges, 
respectively.  The  Show  Global  and  Local  options  affect  whether  only  global  variables  or 
just  local  variables  and  parameters,  respectively,  are  included  in  the  edge  labels.  Hide 
Edge  causes  the  edge  to  disappear.  The  Draw  Edge  options  are  for  respecifying  the  edge 
layout.  The  Mouse  Left  (Middle)  options  assign  the  specified  functions  to  the  left 
(middle)  mouse  buttons.  The  Draw  functions  correspond  to  the  Draw  menu  options.  The 
Toggle  Display  function  changes  the  type  of  edge  label  that  is  shown  on  the  edge.  PUP 
and  Inspect  are  debugging  options.  Abort  closes  the  menu  without  taking  any  action. 


Table  5  Packager  Data  Binding  Edge  Pop-Up  Menu 


PAK;  BINDINGS 
Show  Call  Total  (CS) 

Show  Call  Summary 
Show  Call  Details 
Show  Binding  Total  (IS) 

Show  Binding  Summary 
Show  Binding  Details 
Show  Global  Bindings  Only 
Show  Local  Bindings  Only 
Show  Source  Code 
Hide  Edge 
Draw  Edge  Manually 
Draw  Edge  Automatically 
Mouse  Left = Select 
Mouse  Left = Drag 
Mouse  Middle = Draw  Auto 
Mouse  Middle  =  Draw  Manual 
Mouse  Middle = View  Source 
Mouse  Middle = Toggle  Display 
PUP 
Inspect 
Abort 
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Table  6  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  the  back¬ 
ground  in  the  Packager  view.  The  Cluster  options  invoke  the  algorithms  that  combine 
nodes  into  packages.  Create  Package  creates  a  new  package  node  with  no  declarations. 
The  (De) Select  options  change  the  reverse-video  status  of  nodes,  making  them  (in)sensi- 
tive  to  other  menu  options  that  operate  on  them.  The  Show  options  for  Icons  and  Edges 
cause  hidden  nodes  and  edges,  respectively,  to  reappear.  The  Show  options  for  Data  Bind¬ 
ings  and  Call  Relations  cause  the  specified  kinds  of  edges  to  appear  for  All  nodes,  or  just 
for  Selected  nodes.  The  Hide  options  cause  nodes  and  edges  to  disappear.  The  Push  and 
Pop  options  let  you  move  nodes  down  or  up,  respectively,  in  the  package  hierarchy. 

Table  6  Packager  Background  Pop-Up  Menu 

PAK:  BACKGROUND 
Cluster  by  IS  Once 
Cluster  by  IS  Until  Done 
Cluster  by  CS  Once 
Cluster  by  CS  Until  Done 
Create  Package 
.  Select  All  Packages 
Select  All  Subprograms 
Select  Icons  in  Region 
Deselect  Icons  in  Region 
Deselect  All 
Show  Hidden  Icons 
Show  Hidden  Edges 
Show  Hidden  Icons/Edges 
Show  Edges  of  Selected  Icons 
Show  All  Data  Bindings 
Show  All  Call  Relations 
Show  Selected  Data  Bindings 
Show  Selected  Cal!  Relations 
Hide  All  Edges 
Hide  Edges  of  Selected  Icons 
Hide  Selected  Icons/Edges 
Push  Selected  Icons 
Pop  Selected  Icons 

Pop  Selected  Icons  to  Top _ _ 
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Table  6  Packager  Background  Pop-Up  Menu  (Continued) 


PAK:  BACKGROUND 

Drag _ 

Ascend 
Refresh  View 

Draw  All  Edges  Automatically 

Draw  All  Edges  as  Straight  Lines 

Neutral  Scroll 

Normal  Scale 

Zoom  In 

Zoom  Out 

Arrange  Icons  in  Circle 
Arrange  Selected  Icons  in  Circle 
Arrange  Icons  in  Grid 
Arrange  Selected  Icons  in  Grid 
Mouse  Left = Select 
Mouse  Left = Select 
Mouse  Left = Drag 
Mouse  Middle = View  Source 
Mouse  Middle = Navigate 
PUP 
Inspect 

Inspect _ 


Drag  moves  a  node.  After  choosing  the  Drag  option  for  a  node,  move  the  mouse  to 
a  clear  eirea  on  the  background  while  holding  down  the  left  mouse  button  and  release  it 
at  the  desired  position.  Ascend  replaces  the  current  graph  with  the  parent  package  graph. 
The  Draw  All  Edges  options  let  you  respecify  the  layout  for  all  edges  in  the  graph.  Normal 
Scroll  changes  the  magnification  of  the  current  view  to  a  preset  level.  Neutral  Scale 
changes  the  magnification  of  the  current  view  so  that  all  nodes  are  shown.  The  Arrange 
Icons  options  let  you  move  all  or  selected  nodes  so  that  they  form  a  circle  or  grid.  The 
Mouse  Left  (Middle)  options  assign  the  specified  functions  to  the  left  (middle)  mouse  but¬ 
tons.  The  Navigate  function  implies  Ascend  and  Descend  (Table  3).  The  other  functions 
are  explicitly  Hsted  as  menu  options.  PUP  and  Inspect  are  debugging  options.  Abort  closes 
the  menu  without  taking  any  action. 
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Table  7  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  the  win¬ 
dow  title  bar  of  the  Packager  view.  The  Window  options  let  you  control  the  Packager  win¬ 
dow.  Save  Package  Structure  pops  up  a  window  to  prompt  you  for  a  file  name  in  which 
to  save  the  internal  Packager  representation.  You  can  subsequently  reload  the  file  by  se¬ 
lecting  the  Load  Packager  option  in  Figure  7.  The  Delete  Package  Structure  clears 
the  current  Packager  view.  You  select  the  following  options,  in  the  specified  order,  to  gen¬ 
erate  Ada  code  after  you  are  satisfied  with  the  package  structure.  (You  can  change  the 
structure  and  regenerate  code  as  often  as  you  like.) 

1.  Distribute  Global  Data  Items 

2.  Initialize  Ada  Library 

3.  Generate  Ada  Statements 

4.  Generate  Ada  Code  For  Implicits 

5.  Write  Ada  Files 

6.  Analyze  Ada  Files 

PUP  and  Inspect  are  debugging  options.  Abort  closes  the  menu  without  taking  any 
action. 


Table?  Packager  Window  Pop-Up  Menu 


PAK:  WINDOW 

Clusterby  ISOnce 

Lower  Window 

Hide  Window 

Move  Window 

Reshape  Window 

Reshape  Window 

Refresh  Window 

Print  Window 

Save  Package  Structure 

Delete  Package  Structure 

Distribute  Global  Data  Items 

Initialize  Ada  Library 

Generate  Ada  Statements 

Generate  Ada  Code  For  Implicits 

Write  Ada  Files 

Analyze  Ada  Files 

PUP 

Inspect 

Abort 
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5.3  DATAFLOW  DIAGRAM 


Figure  13  shows  a  sample  top-level  Dataflow  Diagram  (DFD).  It  contains  six  trans¬ 
form  nodes:  RLTJNIT,  RLTJNPUT,  RLT.OUTPUT,  and  RLT.COMPUTE,  RLT_TERM, 
and  RLT_SUSPEND.  The  rectangular  nodes  are  buffer  repositories.  The  arrows  indicate 
the  direction  of  data  flow  between  transform  and  buffer  nodes. 

Figure  14  shows  the  same  top-level  graph  with  most  of  the  nodes  selected  (shown 
in  reverse-video).  Note  that  we  have  moved  the  CURRENT_POWER  buffer  and  directed 
the  DFD  to  display  its  edges,  which  were  hidden  in  Figure  13.  We  captured  the  screen  out¬ 
put  which  is  Figure  14  when  the  mouse  cursor  was  over  the  RLT_OUTPUT  transform. 
The  DFD  outlines  the  node  that  the  cursor  is  currently  on  and  all  adjacent  nodes,  i.e., 
nodes  that  share  an  edge  with  the  current  node.  In  this  case,  all  nonselected  nodes  except 
for  RLT_RL003_OUT  and  RLT_RL004_OUT  are  outlined  because  they  are  adjacent  to 
RLT_OUTPUT.  This  feature  comes  in  handy  with  more  complicated  graphs  or  when  some 
edges  are  hidden. 

We  selected  most  of  the  nonadjacent  (to  RLT_OUTPUT)  nodes  because  we  want  to 
focus  on  the  RLT_OUTPUT  transform.  Figure  15  shows  the  result  of  hiding  the  selected 
nodes,  zooming  in,  and  reshaping  the  PREVIOUS_POWER  node  to  reveal  its  entire  label. 


Figure  13  Dataflow  Diagram  Top-Level  View 
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The  RLT_RLOOn_OUT  transforms  are  not  directly  relevant  to  RLT_OUTPUT  and  we 
could  have  hidden  them  too,  but  we  did  not. 

Figure  16  shows  the  effect  of  descending  into  the  RLT_OUTPUT  transform.  The 
RET  has  replaced  the  top-level  graph  with  that  of  the  RLT_OUTPUT  transform  node. 
This  is  accomplished  by  middle-clicking  on  the  RLT_OUTPUT  node  in  Figure  15,  or  right- 
clicking  on  it  and  choosing  the  Descend  option  from  the  resulting  pop-up  menu  (Table  8). 

Figure  16  depicts  the  same  transformation  as  Figure  15,  but  in  more  detail.  For  ex¬ 
ample,  Figure  15  shows  that  RLT_OUTPUT  transforms  IRARDQ  into  RLDOOl  and 
RLD*,  but  Figure  16  shows  that  it  does  this  by  calling  RLT_RLTADO.  On  the  other  hand, 
statements  in  the  body  of  subprogram  RLT_OUTPUT  transform  CURRENT_POWER 
into  PREVIOUS_POWER. 

RLDOOl  represents  a  single  variable,  but  RLD*  represents  a  collection  (or  record) 
repository.  A  collection  is  a  group  of  repositories  that  the  DFD  may  form  to  reduce  the 
number  of  repository  nodes  in  a  graph.  Another  way  that  the  DFD  reduces  the  number  of 
repositories  is  to  list  more  than  one  variable  or  collection  in  a  single  node,  such  as  the  one 
containing  RLDOOl  and  RLD*  in  Figure  16. 


Figure  16  Dataflow  Diagram  for  RLT_OUTPUT 
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Table  8  lists  the  options  for  menus  that  pop  up  when  you  right-click  on  call  (non-ter¬ 
minal),  leaf  (terminal),  or  body  transform  nodes  in  the  DFD  view.  Descend  causes  the 
package’s  graph  to  replace  the  current  graph.  Reshape  lets  you  change  the  size  and  shape 
of  a  node.  The  Drag  options  allow  you  to  reposition  a  single  node,  all  selected  nodes,  or  all 
nodes  that  have  an  edge  to  the  current  node.  After  choosing  the  Drag  option  for  a  node, 
move  the  mouse  to  a  clear  area  on  the  background  while  holding  down  the  left  mouse  but¬ 
ton  and  release  it  at  the  desired  position.  Edit  Spec  and  Body  open  Emacs  buffers  for  the 
specification  and  body  files,  respectively.  (De)Select  Icon  changes  the  reverse-video  sta¬ 
tus  of  a  node,  making  it  (in)sensitive  to  other  menu  options  that  operate  on  selected  nodes. 


Tables  Dataflow  Diagram  Pop-Up 
Menu  for  Transform  Nodes 


DFD:  CALL  NODE 
DFD:  LEAF  NODE 
DFD:  BODY  NODE 


Descend 

Reshape 

Drag _ 

Drag  Selected  Icons 
Drag  Adjacent  Icons 
Drag  Connected  Icons 
Edit  Spec 
Edit  Body 
Select  Icon 
Select  Adjacent  Icons 
Select  Connected  Icons 
Deselect  Icon 
Deselect  Adjacent  Icons 
Deselect  Connected  Icons 
Mouse  Left = Select 
Mouse  Left = Drag 

Mouse  Middle  =  View  FORTRAN  Code 
Mouse  Middle = View  FORTRAN/Ada  Code 
Mouse  Middle = View  Ada  Code 
Mouse  Middle  =  Navigate 
Mouse  Middle  =  Reshape 
Hide  Icon 
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Tables  Dataflow  Diagram  Pop-Up 
Menu  for  Transform  Nodes  (Continued) 


DFD:  CALL  NODE 
DFD:  LEAF  NODE 
DFD:  BODY  NODE 


Hide  Edges 


Show  Edges 


Show  Local  Variables 


Show  FORTRAN  Source  Code 


Show  FORTRAN/Ada  Source  Code 


Show  Ada  Source  Code 


PUP 


Inspect 


Abort 


The  Mouse  Left  (Middle)  options  assign  the  specified  functions  to  the  left 
(middle)  mouse  buttons.  The  Navigate  function  implies  Ascend  (Table  10)  and  De¬ 
scend.  The  other  functions  are  explicitly  listed  as  menu  options.  Hide  Icon  (Edges) 
causes  the  node  (the  node  edges)  to  disappear.  Show  Edges  causes  all  hidden  edges  to 
reappear.  Show  Local  Variables  pops  up  a  window  that  fists  the  variables  in  the  corre¬ 
sponding  subprogram.  PUP  and  Inspect  are  debugging  options.  Abort  closes  the  menu 
without  taking  any  action. 

Table  9  fists  the  options  for  menus  that  pop  up  when  you  right-click  on  variable  or 
record  (collection)  repository  nodes  in  the  DFD  view.  The  description  of  the  options  is  iden¬ 
tical  to  that  of  Table  8. 


Table  9  Dataflow  Diagram  Pop-Up 
Menu  for  Repository  Nodes 


DFD:  VARIABLE  NODE 
DFD:  RECORD  NODE 


Descend 


Reshape 


Drag 


Drag  Selected  Icons 


Drag  Adjacent  Icons 


Drag  Connected  Icons 


Edit  Spec 
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Tables  Dataflow  Diagram  Pop-Up 
Menu  for  Repository  Nodes  (Continued) 


DFD:  VARIABLE  NODE 
DFD:  RECORD  NODE 


Edit  Body 
Select  Icon 
Select  Adjacent  Icons 
Select  Connected  Icons 
•  Deselect  Icon 
Deselect  Adjacent  Icons 
Deselect  Connected  Icons 
Mouse  Left = Select 
Mouse  Left = Drag 

Mouse  Middle = View  FORTRAN  Code 

Mouse  Middle  =  View  FORTRAN/Ada  Code 

Mouse  Middle = View  Ada  Code 

Mouse  Middle = Navigate 

Mouse  Middle  =  Reshape 

Hide  Icon 

Hide  Edges 

Show  Edges 

PUP 

Inspect 

Abort 


Table  10  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  the 
background  in  the  DFD  view.  Ascend  replaces  the  current  graph  with  the  parent  package 
graph.  The  (De)Select  options  change  the  reverse-video  status  of  nodes,  making  them 
(in)sensitive  to  other  menu  options  that  operate  on  them.  The  Show  options  for  Icons  and 
Edges  cause  hidden  nodes  and  edges,  respectively,  to  reappear.  The  Ride  options  cause 
nodes  and  edges  to  disappear. 
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Table  10  Dataflow  Diagram  Pop-Up 
Menu  for  Background 


DFD:  BACKGROUND 

Ascend 

Select  All  Transform  Nodes 
Select  All  Call  Nodes 
Select  All  Leaf  Nodes 
Select  All  Data  Nodes 
Select  Icons  in  Region 
Deselect  Icons  in  Region 
Deselect  All 
Show  Hidden  Icons 
Show  Hidden  Edges 
Show  Hidden  Icons/Edges 
Show  Edges  of  Selected  Icons 
Hide  All  Edges 
Hide  Edges  of  Selected  Icons 
Hide  Selected  Icons/Edges 
Drag 

Refresh  View 

Neutral  Scroll 

Normal  Scale 

Zoom  In 

Zoom  Out 

Arrange  Icons 

Arrange  Icons  in  Circle 

Arrange  Selected  Icons  in  Circle 

Arrange  Icons  in  Grid 

Arrange  Selected  Icons  in  Grid 

Mouse  Left = Select 

Mouse  Left  =  Drag 

Mouse  Middle = View  Source 

Mouse  Middle = Navigate 

PUP 

Inspect 

Abort 
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Drag  moves  a  node.  After  choosing  the  Drag  option  for  a  node,  move  the  mouse  to 
a  clear  area  on  the  backgroxmd  while  holding  down  the  left  mouse  button  and  release  it 
at  the  desired  position.  Normal  Scroll  changes  the  magnification  of  the  current  view  to  a 
preset  level.  Neutral  Scale  changes  the  magnification  of  the  cxirrent  view  so  that  all  nodes 
are  shown.  The  Arrange  Icons  options  let  you  move  all  or  selected  nodes  so  that  they  form 
a  circle  or  grid.  The  Mouse  Left  (Middle)  options  assign  the  specified  functions  to  the  left 
(middle)  mouse  buttons.  The  Navigate  function  implies  Ascend  and  Descend  (Table  8  and 
Table  9).  The  other  fimctions  are  explicitly  listed  as  menu  options.  PUP  and  Inspect  are 
debugging  options.  Abort  closes  the  menu  without  taking  any  action. 


Table  11  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  the  win¬ 
dow  title  bar  in  the  DFD  view.  The  Window  options  let  you  control  the  DFD  window.  Save 
DFD  Structure  pops  up  a  window  to  prompt  you  for  a  file  name  in  which  to  save  the  in¬ 
ternal  DFD  representation.  You  can  subsequently  reload  the  file  by  selecting  the  Load 
DFD  option  in  Figure  7.  The  Edit  DFD  Name  option  lets  you  change  the  window  title  for 
the  top-level  DFD  graph.  The  name  is  also  the  default  file  name  for  the  Save  DFD  Struc¬ 
ture  option.  PUP  and  Inspect  are  debugging  options.  Abort  closes  the  menu  without 
taking  any  action. 

Table  11  Dataflow  Diagram  Pop-Up 
Menu  for  Window 

DFD:  WINDOW 

Lower  Window 

Hide  Window 

Move  Window 

Reshape  Window 

Refresh  Window 

Print  Window 

Save  DFD  Structure 

Edit  DFD  Name 

Distribute  Global  Data  Items 

Initialize  Ada  Library 

Generate  Ada  Statements 

Generate  Ada  Code  For  Implicits 

Write  Ada  Files 

Analyze  Ada  Files 

PUP 

Inspect 

Abort 
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5.4  CALL  DIAGRAM 


Figure  17  shows  a  sample  Call  Diagram  (CD)  as  it  appears  immediately  after  gen¬ 
eration.  The  "c-88”  at  the  top  indicates  that  the  names  of  88  subprograms  follow.  You  may 
expand  a  subprogram  by  right-clicking  on  it  and  choosing  the  Show  Calls  or  Show 
Called  By  pop-up  menu  options  (see  Table  12). 

These  and  other  options  in  the  menus  operate  on  the  subprogram  that  you  right- 
chcked  on  to  pop-up  the  menu,  i.e.,  the  selected  subprogram.  You  may  also  designate  one 
or  more  selected  subprograms  by  left-clicking  on  them.  Left-clicking  toggles  the  selected 
status  of  a  subprogram.  The  CD  distinguishes  selected  subprograms  by  displaying  them 
in  reverse  video. 

Figure  18  shows  the  CD  after  expanding  FCR_DR013  to  show  the  subprograms 
that  call  it  (only  FCR_OUTPUT  calls  FCR_DR013)  and  FCRS16  to  show  the  subprograms 
that  it  calls  (FCRIC,  FCRSBY,  etc.).  The  information  that  the  CD  displays  for  calls  in¬ 
cludes  the  subprogram  names  and  the  nximher  of  calls  that  the  selected  subprogram 
makes  to  each  one.  Figure  18  shows  that  FCRS16  calls  FCRIC  once  and  FCRMOD  twice. 

Figin-e  19  shows  the  same  CD  as  Figure  18,  except  that  it  is  positioned  to  start  with 
FCRS16.  You  may  expand  any  subprogram  in  the  CD  to  show  calling  information. 


RET  Main  Window 


System:  C'68 

rcRirr 
rCR  DR013 
rcR”Dr03i 
rcRjma 
rCFSB^ 
tCFSlQ 
rCR  OR03£ 
pcr"droii 

PCR^STUBOLS 

Tcma 

rcRcxr 

FCRSAD 

pcRcitr 

rCRS16 

rcRcs 

PCR_BP068 

rcRsco 

pcaisTJ 

pcR_nr033 

PCRBIT 

rCRMJT 

PCR_DRD33 

FCRJ]R032 

fRiTE_ina:_ESP 

FCKmi 

FCR_AD0 

FCIWS 

SET  SCALED  HOE 

rcsScH 

FCRDEG 

FCR&HR 


Figure  17  Initial  Call  Diagram 
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RET  Main- Window^: 


►»  CD 


System:  c-88 
rCRIPF 
rCR_DR013 

Called  by: 
fCR  OTOUT 

rcR_Dr03i 

rCR^TERM 

rCROTT 

rCRREQ 

PCR  DR03fi 

PCR_DR011 

PCR_S7HB0LS 

rCRHDX 

rCRGXT 

rCRSAD 

FCRGHT 

rcRsis 

Calls: 

PCRIC  ; 

1 

PCRSBY 

1 

PCRIN  : 

1 

rCRHOD 

2 

PCRCSR 

2 

FCRREQ 

2 

FCRurr 

2 

FCRBIM 

2 

FCRSM 

1 

FCRTDP 

1 

FCRSDP 

1 

FCaiVlD 

2 

FCRAXy 

1 

FCRPRC 

1 

Figure  18  Expanded  Call  Diagram 


Figure  19  Further  Expanded  Call  Diagram 
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Figure  19  shows  the  subprograms  that  FCRANT  calls.  It  calls  SQRT  three  times,  for  ex¬ 
ample.  SQRT  is  called  by  FCRTWS  and  others.  You  may  expand  subprograms  in  the  CD 
like  this  to  any  depth. 

Table  12  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  a  sub¬ 
program  name  in  the  CD  view.  Hide  Self  causes  the  subprogram  to  disappear  from  the 
display.  The  pop-up  menu  may  show  either  the  Show  Calls  or  Hide  Calls  options  de¬ 
pending  on  whether  the  CD  already  displays  the  subprograms  that  the  selected  subpro¬ 
gram  calls.  The  pop-up  menu  may  show  either  the  Show  Called  By  or  Hide  Called  By 
options  depending  on  whether  the  CD  already  displays  the  subprograms  that  call  the  se¬ 
lected  subprogram.  View  Source  pops  up  the  FORTRAN  Somrce  Code  Listing  view  for 
the  selected  subprogram.  PUP  and  Inspect  are  debugging  options.  Abort  closes  the 
menu  without  taking  any  action. 


Table  12  Call  Diagram  Pop-up  Menu  for  Object 


CD:  OBJECT 

Hide  Self 
Show  Calls 
Hide  Calls 
Show  Called  By 
Hide  Called  By 
View  Source 
PUP 
Abort 


Table  13  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  the 
background  in  the  CD  view.  Hide  Self  causes  the  currently  selected  subprograms  to  dis¬ 
appear  from  the  display.  Show  Kids  causes  the  information  nested  below  the  selected 
subprograms  to  reappear  if  it  has  been  hidden.  View  Source  pops  up  the  FORTRAN 
Source  Code  Listing  view  for  the  selected  subprograms.  Deselect  causes  all  selected  sub¬ 
programs  to  become  insensitive  to  the  options  that  operate  on  selected  subprograms,  such 
as  Hide  Self.  PUP  and  Inspect  are  debugging  options.  Abort  closes  the  menu  without 
taking  any  action. 
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Table  13  Call  Diagram  Pop-Up  Menu 
for  Background 


CD:  BACKGROUND 

Hide  Self _ 

Show  Kids 
View  Source 
Deselect 
PUP 
Abort 


Table  14  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  the  win¬ 
dow  title  bar  of  the  CD  view.  The  Lower,  Hide,  Move,  Reshape,  and  Refresh  options 
let  you  control  the  CD  window.  Output  causes  the  RET  prototype  to  prompt  you  for  a  file 
name  and  print  the  CD  view  to  the  file.  Hyperlink  On  and  Hyperlink  Off  are  disabled 
in  the  RET  prototype.  Bfide  Self  causes  the  selected  subprograms  to  disappear.  Show 
Kids  causes  the  information  nested  below  the  selected  subprograms  to  reappear.  Abort 
closes  the  menu  without  taking  any  action. 


Table  14  Call  Diagram  Pop-Up  Menu 
for  Window 


CD:  WINDOW 

Lower 

Hide _ 

Move 
Reshape 
Refresh 
Output 
Hyperlink  On 
Hyperlink  Off 

Hide  Self _ 

Show  Kids 

Deselect 

Abort 
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5.5  DECLARATION  DIAGRAM 


Figure  20  shows  a  sample  Declaration  Diagram  (DED)  as  it  appears  immediately 
after  generation.  The  “c-91”  at  the  top  indicates  that  the  names  of  91  subprograms  and 
common  blocks  (called  hnes)  follow.  The  “c-4  *”  on  the  third  line  indicates  that  four  lines 
are  hidden  below  FCR.  The  indicates  that  the  lines  xmder  FCR  are  hidden,  i.e.,  not 
shown.  In  contrast,  the  absence  of  an  asterisk  in  “system  c-91”  impHes  that  91  lines  are 
shown  imder  “system.” 

A  line  without  an  asterisk  is  said  to  be  expanded  and  a  hne  with  an  asterisk  is  said 
to  be  contracted.  The  asterisk  is  a  sturogate  for  the  missing  information.  You  may  expand 
or  contract  a  subprogram  or  common  block  by  middle-clicking  on  it.  Alternatively,  you 
may  right-click  on  it  and  choose  the  Show  Kids  or  Hide  Self  pop-up  menu  options  (see 
Table  15). 

These  and  other  options  in  the  menus  operate  on  the  subprogram  or  common  block 
that  you  right-clicked  on  to  pop-up  the  menu,  i.e.,  the  selected  line.  You  may  also  designate 
one  or  more  selected  lines  by  left-clicking  on  them.  Left-clicking  toggles  the  selected  status 
of  a  line.  The  DED  distinguishes  selected  lines  by  displaying  them  in  reverse  video. 


RET  Main  Window 


syatea  c-91 

couum  blocks  c-1  * 

rCR“c-4  * 


rCSiCH  c-4  * 

FCRiGR  * 
rCRALL  c-4  * 
rCRMIR  c-4  ♦ 

PCRA.VT  c-4  • 

PCRAX7  C-4  * 

PCSBCH  c-4  ♦ 

PCRBEH  C-4  * 

PCR8IT  C-4  ♦ 

PCRaX  c-4  * 
pcRon:  C-4  * 

PCRCSR  c-4  ♦ 

PCRO&T  couon  blocks  c-1  * 
PCRDEG  c-4  ♦ 

PCRDET  C-4  * 

PCRCDP  c-4  • 

PCRCK  c-4  * 

PCRCHT  c-4  * 

PCRCRD  C-4  • 

PCRCXr  C-4  * 

PCRIC  c-4  * 

PCRIPP  c-4  ♦ 

PCRIN  c-4  * 

PCRiaH  c-4  * 

PCmttP  c-4  * 

PCRMOD  c-4  ♦ 
pourac  c-4  * 

PCROUT  c-4  * 

PCRPRC  c-4  ♦ 


Figure  20  Initial  Declaration  Diagram 
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Figure  21  shows  the  DED  after  expanding  “ALL_SHRMEM  common  blocks”  to 
show  the  sole  common  block  (ALL_SHRMEM),  and  the  single  variable  that  it  defines 
(SHRMEM).  FORTRAN  \infortunately  allows  multiple  common  blocks  with  the  same 
name  but  different  definitions.  If  ALL_SHRMEM  had  been  multiply  defined  in  this  way, 
the  DED  would  have  shown  more  than  one  common  block  with  that  name,  but  it  only 
shows  one  in  this  case. 

Ten  subprograms  are  selected  in  Figure  21.  The  first  hne  reveals  that  a  line  is  hid¬ 
den  somewhere  in  the  system  by  the  “h-1.”  Figure  22  shows  the  results  of  performing  sev¬ 
eral  operations  on  the  DED  in  Figure  21.  The  “h-11”  at  the  top  of  Figure  22  indicates  that 
the  10  lines  that  were  selected  in  Figure  21  are  now  hidden  (in  addition  to  the  one  line  that 
was  already  hidden,  for  a  total  of  11).  This  change  resulted  from  the  Hide  Self  option  of 
the  pop-up  menu  in  Table  16. 

Figure  22  demonstrates  the  results  of  expanding  the  FCRDAT  common  block  and 
two  of  the  variables  (INDUNZ  and  ISDFL)  that  it  contains.  The  line  “FCRDAT  c-390” 
shows  that  the  common  block  defines  390  variables.  INDUNZ  is  an  array  of  10  integers, 
declared  on  line  266  in  file  AVM_FCR_LCM.FOR,  and  referenced  on  line  434  in  file 
fcrtfin.for  and  in  file  fcrmux.for. 


RET  Main  Window 


system  c-91  h-1 

ALL^SBEHEIf  common  blocks  c-1 

*T  T.  CHHWnC  C>1 

”SHRaOI 

type:  INIECIR  «  2  (  0:  2S214; 
declared:  BLX^SKR.BLK^SHRMCM. 

PKC_SHD,ALL~SHRlirM. 

used: 

rCR  c-4  * 


rCRCSR  c-4  • 


FCSDhT  common  blocks  c-l  * 

rCRDEC  c-4  * 

rCRDET  c-4  * 

rCRCDP  C-4  • 

rCRCK  c-4  * 

rCROMT  c-4  ♦ 

rCRCRn  e-4  • 

rCRCXT  c-4  * 

PCBIC  c-4  * 
rcRUT  c-4  ♦ 
rCRIN  c-4  * 


Figure  2 1  Declaration  Diagram  With  Selected  Subprograms 
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RET  Main  Window 


systea  c-91  h-11 

aiX^SHRHEM  coaaon  blocks  c-1 
iU._SHR)ffiM  c-l 
SHIQIEII 

type:  I»TEG£R  *2(0:  2S214: 
declared:  BLK_SHR_BLK_SHRMEN. 

PKG_SMd”4U.~SHRMEK. 

used: 

PCR  c-4  * 

PCRCSR  c-4  ♦ 

FCRDiT  coaaon  blocks  c-l 
rCRDAT  C-39D 

iccm  * 

dDUKZ 

type:  INIEGER  *  2  (  10) 
declared:  AVXjrCR_LCK. FOR  26i 

used:  fcrtfa. f or  434 
fcraux.  for  332 

TRATn  * 

IRDETZ  * 

ISOFL 

type:  fflUGrR  *2(2) 
declared:  AVMJ*CR_LCH.rOR  2€i 

used:  fcra^.for  156 
fcrgxy.  for  132 
fcrgd^.for  333  324  310 

rwsz  * 


Figure  22  Declaration  Diagram  With  Expanded  Common  Blocks 

Figure  23  shows  two  expanded  subprograms.  Near  the  bottom  and  indented  imder 
FCRSPT  are  four  lines  that  provide  information  on  formal  parameters,  constants,  vari¬ 
ables,  and  include  statements  in  the  subprogram.  FCRSPT  has  no  formal  parameters  and 
declares  no  data  objects,  but  it  includes  three  files.  Near  the  top,  FCRSDP  is  shown  to  de¬ 
clare  eight  variables  and  include  four  files.  The  “variables”  and  “includes”  lines  are  ex¬ 
panded  to  reveal  the  variable  and  include  file  names,  respectively.  Variable  NJAM  is  also 
expanded. 


Table  15  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  a  line 
in  the  DED  view.  Hide  Self  causes  the  line  to  disappear  from  the  display.  Show  Kids 
causes  the  information  nested  below  the  line  to  reappear  if  it  was  hidden.  View  Source 
pops  up  the  FORTRAN  Source  Code  Listing  view  for  the  line  if  it  is  a  subprogram  hne. 
PUP  is  a  debugging  option.  Abort  closes  the  menu  without  taking  any  action. 
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RET  Main  Window 


FCRSDP 

foruls 
constants 
variables  c-8 
AZJi}12  * 

I  * 

JAH  * 

XJAX 

type:  mSEGCR  *  2 
declared:  fcrsdp. for  134 

used:  fcrsdp. for  327 

AZJAXl  * 
nrccif  * 

RRSC&L  * 

includes  c-4 

blk_shr_bij:_shrkeh.  for 

PRC_S2ID_AaIsHRIEX.  FOR 
AVK”FCR”LClfrFOR 
&VX  FCR  CONSTMUS.FOR 
FCRSEA  c-4  • 

FCRSGD  c-4  ♦ 

FCRSPT  c-4 
formals 
constants 
variables 
includes  c-3  * 

FCRSTJ  c-4  ♦ 

FCRSTT  c-4  * 

FCR3DP  c-4  ♦ 


Figure  23  Declaration  Diagram  With  Expanded  Subprograms 


Tablets  Declaration  Diagram  Pop-Up 
Menu  for  Object 


DED:  OBJECT 

Hide  Self 
Show  Kids 
View  Source 
PUP 
Abort 


Table  16  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  the 
background  in  the  DED  view.  Hide  Self  causes  the  currently  selected  line(s)  to  disappear 
from  the  display.  Show  Kids  causes  the  information  nested  below  the  selected  line(s)  to 
reappear  if  it  has  been  hidden.  View  Source  pops  up  the  FORTRAN  Source  Code  Listing 
view  for  the  selected  line  if  it  is  a  subprogram  line.  Deselect  causes  all  selected  lines  to 
become  insensitive  to  the  options  that  operate  on  selected  lines,  such  as  Hide  Self.  PUP 
is  a  debugging  option.  Abort  closes  the  menu  without  taking  any  action. 
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Table  16  Declaration  Diagram  Pop-Up 
Menu  for  Background 


DED:  BACKGROUND 

Hide  Self 
Show  Kids 
View  Source 
Deselect 

PUP _ 

Abort 


Table  17  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  the  win¬ 
dow  title  bar  of  the  DED  view.  The  Lower,  Hide,  Move,  Reshape,  and  Refresh  options 
let  you  control  the  DED  window.  Output  causes  the  RET  prototype  to  prompt  you  for  a 
file  name  and  print  the  DED  view  to  the  file.  Hyperlink  On  and  Hyperlink  Off  are  dis¬ 
abled  in  the  RET  prototype.  PUP  is  a  debugging  option.  Abort  closes  the  menu  without 
taking  any  action. 


Table  17  Declaration  Diagram  Pop-Up 
Menu  for  Window 


DED:  WINDOW 


Lower 


Hide 


Move 

Reshape 

Refresh 


Output 
Hyperlink  On 
Hyperlink  Off 
PUP 


Abort 
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5.6  FORTRAN  SOURCE  CODE  LISTING 


Figure  24  shows  a  sample  FORTRAN,  and  the  corresponding  Ada  Soiirce  Code 
Listing  view.  The  IF  statement  near  the  center  of  the  Ada  view  calls  an  external  function 
(IS_SET)  and  an  external  procedure  (RESET).  The  explicit  type  conversion  of  the  return 
value  of  IS_SET  to  BOOLEAN  is  superfluous  (see  Figure  12).  Section  5.7  explains  how  to 
edit  the  generated  Ada  source  code  to  remove  the  type  conversion. 

Table  18  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  a 
FORTRAN  statement  in  the  FORTRAN  Source  Code  Listing  view.  The  Select  (Deselect) 
Statement  option  makes  the  statement  (in)sensitive  to  other  options  that  operate  on 
statements,  such  as  the  Translate  options.  The  Translate  options  translate  the  selected 
statement(s)  to  Ada  code  and  either  insert  the  resulting  Ada  statements  into  the  subpro¬ 
gram  body  on  the  RHS,  print  them  to  the  *REFINE*  Emacs  bviffer,  or  invoke  the  Inspector 
debugging  utility  on  them,  with  respect  to  the  order  of  the  options  given  in  the  table.  In¬ 
spect,  PUP,  MCN,  and  PN  are  debugging  options.  Abort  closes  the  menu  without  taking 
any  action. 


RET  Main  Window 


Analysis  Views  Reshape 


INCLODC  'pJcg;_sKd_gen_3hniam.  for'  !  dew  reiul 
ncCLDDE  *pkg_a«d_con3tant9.for'  I  dew  cemoJ 
mCLCDE  'xSaci  pt*  jecm.  for'  !  dew  removed  fyii 

LOGICAL*!  IS^SET 

CCBC  begin  new  code 
C  Check  to  eee  if  the  power  to  the  model  ie 
C  do  not  continue  proceaeing. 

C 

Current  Power  -  .FALSE. 

IF  (  Vap_iat<l).EQ.l  )  TSES 
Current^Power  *  .SIOE. 

EHDIF 


Only  proceaa  the  code  if  the  power  to  the 


IF  (  CurrBnt_Pover  )  THEN 
CEDC  end  new  code 
C 

Oat  the  FCC  to  8LT  input  data 

IF  (  IS  SETCFOfifi  FLAO)  )  TBEN 
CALL  HLT  FOSS  IN 
CALL  RESEXCFOeS.FLAO) 
niDIF 


Call  the  aubroutine  to  get  the  data  iteaa 
Ihe  plane  model  ia  refered  to  aa  the  refer^ 
model  aet. 

CALL  RLT_RCr_IK 

Reaet  the  fiLT  internal  mode  word 
W9Z  •  '0*0 


CEDC 

C 


RE3TIRN 

END 


procedure  RLT^INPOT  ia  begin 
—ESC  begin  new  code 
—  Check  to  aee  if  the  power  to  the  modei 
—  do  not  continue  proceaaing. 

CORRENT  POWER  :•  FALSE; 
if  WAP_RLT  (  1)  -  1 
then  CORRENT^POWER  TOOE; 
end  if; 

—  Only  proceaa  the  code  if  the  power  to 

if  CtIRRENr_POWER 
then  — EOC  end  new  code 

—  Oet  the  FCC  to  RLT  input  data 

if  BOOLEAN 

(  BCURNALS.  IS  SET 

(  BOOLEAN  (  F066_rLAC)>) 
then  RLT^FOSS  IN; 

EXcErHALS.  RESET 

(  BOOLEAN  (  FOSE^FLAC)); 

and  if; 

—  Call  the  aubroutine  to  get  the 
—  The  plane  model  ia  refered  to 
—  model  aet. 

HLT_REF_^IM; 

—  Reaet  the  RLT  internal  mode  wo]| 

NVZ  :•  StOSi 

end  if; 
return; 

end  RLT_nJPUT; 
procedure  RLT_1NP0T; 


Figure  24  Source  Code  Listings 
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Table  18  FORTRAN  Pop-Up  Menu 
for  Statement 


FORTRAN  SRC 

Select  Statement 

Deselect  Statement 

T ranslate  to  Ada  Body 

Translate  to  Ada  and  Print 

Translate  to  Ada  and  Inspect 

Inspect 

PUP 

MCN 

PN 

Abort 


Table  19  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  a 
FORTRAN  subprogram  in  the  FORTRAN  Source  Code  Listing  view.  The  Select  (Dese¬ 
lect)  All  Statements  option  makes  all  statements  in  the  view  (in)sensitive  to  other  op¬ 
tions  that  operate  on  statements,  such  as  the  Translate  options. 


Table  19  FORTRAN  Pop-Up  Menu 
for  Subprogram 


FORTRAN SRC 
Select  All  Statements 
Deselect  AH  Statements 
Show  Parent  Unit 
Show  Only  This  Unit 
Show  Corresponding  Ada  Body 
T ranslate  to  Ada  Body 
Translate  to  Ada  and  Print 
Translate  to  Ada  and  Inspect 
Inspect 
PUP 
MCN 
PN 
Abort 
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Show  Parent  Unit  causes  the  DED  to  show  the  compilation  unit  associated  with 
the  subprogram  in  lieu  of  the  subprogram.  The  practical  and  visible  effect  of  this  option 
is  to  show  the  comments  that  precede  the  SUBPROGRAM  statement.  Show  Only  This 
Unit  reverses  the  above  operation,  causing  the  DED  to  show  the  subprogram  associated 
with  the  compilation  unit  in  lieu  of  the  compilation  unit.  The  practical  and  visible  effect 
of  this  option  is  to  remove  the  comments  that  precede  the  SUBPROGRAM  statement  from 
the  display.  Show  Corresponding  Ada  Body  displays,  in  the  Ada  Soiurce  Code  Listing 
view,  the  Ada  body  associated  with  the  FORTRAN  subprogram. 

The  Translate  options  translate  the  selected  statement(s)  to  Ada  code  and  either 
insert  the  resulting  Ada  statements  into  the  subprogram  body  on  the  RHS,  print  them  to 
the  *REFINE*  Emacs  buffer,  or  invoke  the  Inspector  debugging  utility  on  them,  with  re¬ 
spect  to  the  order  of  the  options  given  in  the  table.  Inspect,  PUP,  MCN,  and  PN  are  de¬ 
bugging  options.  Abort  closes  the  menu  without  taking  any  action. 

Table  20  lists  the  options  in  the  menu  that  pops  up  when  you  right-chck  on  the 
background  in  the  FORTRAN  Source  Code  Listing  view.  Deselect  All  makes  all  state¬ 
ments  in  the  view  insensitive  to  other  options  that  operate  on  statements,  such  as  the 
Translate  options  in  Table  19.  Inspect,  PUP,  MCN,  and  PN  are  debugging  options. 
Abort  closes  the  menu  without  taking  any  action. 

Table  20  FORTRAN  Pop-Up  Menu 
for  Background 

FORTRAN  SRC  BACKGROUND 

Deselect  All 

Inspect 

PUP 

MCN 

PN 

Abort 

Table  21  hsts  the  options  in  the  menu  that  pops  up  when  you  right-click  on  the  title 
bar  of  the  FORTRAN  Source  Code  Listing  view.  The  Lower,  Hide,  Move,  Reshape,  Re¬ 
fresh,  and  Redraw  Window  options  let  you  control  the  window.  Output  Window 
causes  the  RET  prototype  to  prompt  you  for  a  file  name  and  print  the  FORTRAN  source 
code  to  the  file.  Hyperlink  On  and  Hyperlink  Off  are  disabled  in  the  RET  prototype. 
Inspect,  PUP,  MCN,  and  PN  are  debugging  options.  Abort  closes  the  menu  without  tak¬ 
ing  any  action. 
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Table  21  FORTRAN  Pop-Up  Menu 
for  Window 


FORTRAN  SRC  WINDOW 

Lower  Window 
Hide  Window 
Move  Window 
Reshape  Window 
Refresh  Window 
Redraw  Window 
Output  Window 
Hyperlink  On 
Hyperlink  Off 
Inspect 

PUP _ 

MCN _ 

PN 

Abort 


5.7  ADA  SOURCE  CODE  LISTING 

Figure  25  shows  the  FORTRAN  Source  Code  Listing  view  from  Figure  24,  and  a 
modification  of  the  Ada  Source  Code  Listing  view  from  Figure  24.  You  may  modify  the  Ada 
sotirce  code  by  choosing  the  Edit  Body  option  from  Table  3,  Table  4,  Table  8,  or  Table  9, 
editing  the  resulting  Emacs  buffer,  saving  the  file,  and  then  choosing  the  Analyze  Ada 
Files  option  from  Table  7  or  Table  11. 

We  reformatted  the  Ada  soxurce  code  in  Figure  25  via  Emacs,  but  you  may  modify 
the  source  code  file  on  the  hard  disk  by  any  means,  including  the  execution  of  an  Ada 
pretty  printer  (if  one  is  available;  the  RET  prototype  doesn’t  provide  one)  outside  of  the 
RET  prototype.  We  rearranged  the  comments  and  indentation,  and  removed  the  super¬ 
fluous  BOOLEAN  type  conversion. 

Table  22  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  an  Ada 
statement  in  the  Ada  Soiirce  Code  Listing  view.  The  Select  (Deselect)  Statement  option 
makes  the  statement  (in)sensitive  to  other  options  that  operate  on  statements,  such  as  the 
Delete  Statements  option.  The  Move  Statements  Before  and  After  options  let  you 
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RET  Main  Window 


Analysis  Views  Reshape 


CEDC 

C 

c 

c 


CEDC 

C 

c 

c 


Fortran  Source 


INCLUDE  'pJtg_smd_gen_shr»em.fcl 
INCLUDE  ‘pkL3»d_con3tanta.  foi| 
DTCLUDE  'pJtgjjrmI»c*.for'  !  (' 

LOClCiL*!  IS^SEX 

begin  nev  code 
Check  to  see  if  the  power  to 
do  not  continue  pcoceeoing. 

Current  Power  ■  .PhLSE. 
nr  (  v^^RitCD.EQ.i  )  ohen 
Cutrent^Power  •  .TBUE. 

ENDIF 

Only  process  the  code  if  the  |j 

IT  (  Current_PoweE  )  THEN 
end  xtew  code 

Get  the  PCC  to  RLT  input  data 

IP  (  IS  SETCPOSS^PLM)  )  Td 
caLL’KLT^poee^iN 
CALL  2tESEr(P066_PLA6) 
ENDIP 


Call  the  subroutine  to  get  th^ 
TSie  plane  aodel  is  refered  to 
aodel  set. 

CALL  RLT_REF^1N 


Reset  the  RLT  internal  node  w| 
KSZ  •  'O'O 


CEDC 

C 


procedure  RLT^INPUT  is 
begin 

— EDC  begin  nev  code 

—  Check  to  see  if  the  power  to  the  nodel  is  turned  0K| 
--  If  it  is  off.  then  do  not  continue  processing. 
CURRENT  POVER  PALSE; 
if  PAP_RLT  (1)  -  1  then 
CtJRRENT^POflER  :•  TRUE; 
end  if; 

—  Only  process  the  code  if  the  power  to  the  RLT  is  tuj 
if  CURRENT^POUER  then 

—ESC  end  new  code 

if  EnERSALS.IS_SET(BOOLEAN(F066_rLAC))  then 

RLT  P066  IN:  —  Get  the  PCC  to  RLT  irg>ut  data 
nnZRHALS.  RESET  (BOOLEAN (rOSe_rLAC) ) ; 
end  if; 

—  Call  the  subroutine  to  get  the  data  items  neededj 
~  the  plane  model.  The  plane  model  is  refered  to 
reference  model  in  the  Block  30  model  set. 
RLT^REP^IH; 

irvz  ;•  e#C/;  —  Reset  the  RLT  internal  mode  word 

end  if: 
return: 

end  RLT_.lHPUr: 
procedure  HLT^IHPUT: 


Figure  25  Modified  Ada  Source  Code  Listing 

reorder  the  statements  by  moving  the  selected  statements  before  or  after  the  statement. 
Delete  Statements  removes  the  selected  statements  from  the  display.  (If  you  modify  an 
Ada  Source  Code  Listing  view  via  the  Delete  or  Move  options  in  Table  22,  you  must 
choose  the  Redraw  option  in  Table  24  to  update  the  view  or  you  will  not  see  the  changes.) 
Inspect,  PUP,  MCN,  and  PN  are  debugging  options.  Abort  closes  the  menu  without  tak¬ 
ing  any  action. 

Table  22  Modified  Ada  Source  Code  Listing 

ADA  SRC 

Select  Statement 

Deselect  Statement 

Move  Statements  Before 

Move  Statements  After 

Delete  Statements 

Inspect 

PUP 

MCN 

PN 

Abort 
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Table  23  lists  the  options  in  the  menu  that  pops  up  when  you  right-chck  on  an  Ada 
subprogram  body  or  specification  in  the  Ada  Somce  Code  Listing  view.  The  Select  (Dese¬ 
lect)  All  Statements  option  makes  all  statements  in  the  view  (in)sensitive  to  other  op¬ 
tions  that  operate  on  statements.  Show  Parent  Unit  causes  the  view  to  show  the 
compilation  rniit  associated  with  the  subprogram  body  or  specification.  The  practical  and 
visible  effect  of  this  option  is  to  show  the  Ada  package  that  declares  the  subprogram  body 
or  specification.  Show  Only  This  Unit  reverses  the  above  operation,  causing  the  view  to 
show  the  subprogram  body  and  specification  associated  with  the  compilation  unit.  The 
practical  and  visible  effect  of  this  option  is  to  focus  in  on  the  declarations  of  a  specific  sub¬ 
program  in  the  package.  Inspect,  PUP,  MCN,  and  PN  are  debugging  options.  Abort 
closes  the  menu  without  taking  any  action. 

Table  23  Ada  Pop-Up  Menu 
for  Subprogram 

ADA SRC 

Select  All  Statements 

Deselect  All  Statements 

Show  Parent  Unit 

Show  Only  This  Unit 

Inspect 

PUP 

MCN 

PN 

Abort 


Table  24  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  the 
background  in  the  Ada  Source  Code  Listing  view.  Deselect  All  makes  all  statements  in 
the  view  insensitive  to  other  options  that  operate  on  statements,  such  as  the  Delete  Se¬ 
lected  Statements  option.  Delete  Selected  Statements  removes  the  selected  state¬ 
ments  from  the  view.  Inspect,  PUP,  MCN,  and  PN  are  debugging  options.  Abort  closes 
the  menu  without  taking  any  action. 
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Table  24  Ada  Pop-Up  Menu 
for  Background 


ADA SRC  BACKGROUND 

Deselect  All 

Deselect  Selected  Statements 
Inspect 

PUP _ 

MCN 
■  PN 
Abort 


Table  25  lists  the  options  in  the  menu  that  pops  up  when  you  right-click  on  the  title 
bar  of  the  Ada  Source  Code  Listing  view.  The  Lower,  Ehde,  Move,  Reshape,  Refresh, 
and  Redraw  Window  options  let  you  control  the  window.  (If  you  modify  an  Ada  Source 
Code  Listing  view  via  the  Delete  or  Move  options  in  Table  22,  or  the  Delete  Selected 
Statements  option  in  Table  24,  you  must  choose  the  Redraw  option  in  Table  25  to  up¬ 
date  the  view  or  you  will  not  see  the  changes.)  Output  Window  causes  the  RET  prototype 
to  prompt  you  for  a  file  name  and  print  the  Ada  source  code  to  the  file.  Hyperlink  On  and 
Hyperlink  Off  are  disabled  in  the  RET  prototype.  Inspect,  PUP,  MCN,  and  PN  are  de¬ 
bugging  options.  Abort  closes  the  menu  without  taking  any  action. 

Table  25  Ada  Pop-Up  Menu  for  Window 

ADASRC  WINDOW 

LowerWindow 

Hide  Window 

Move  Window 

Reshape  Window 

Refresh  Window 

Redraw  Window 

Output  Window 

Hyperlink  On 

Hyperlink  Off 

Inspect 

PUP 

MCN 

PN 

Abort 
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APPENDIX  A 

ACRONYMS  FOR  VOLUME  I 


ASG  -  Abstract  S3nitax  Graph 

ASRET  —  Avionics  Software  Reengineering  Technology 
ASTS  -  Avionics  Software  Technology  Support 
CD  —  Call  Diagram 

CS  —  Common  Clients  and  Suppliers  Metric 

DED  -  Declaration  Diagram 

DFD  —  Data  Flow  Diagram 

ECS  —  Embedded  Computer  System 

IS  -  Interconnection  Strength  Metric 

LHS- Left-Hand  Side 

LRM  —  Language  Reference  Manual 

PACK  —  Packager  View 

RET  -  Reengineering  Tool 

RHS  -  Right-Hand  Side 

SCL  —  Source  Code  Listing 

WL/AAAF-S  -  Software  Concepts  Group,  Avionics  Logistics  Branch,  Wright  Laboratory 
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